前提：由於slave磁盤未及時擴容原因導致磁盤即將寫滿，為了不影響業務將slave實例里一個10G的庫drop了（項目前期建的庫，數據現在已不使用了），然后又drop了master上的該庫（對於大庫建議先drop或truncate表再drop庫，否則可能導致磁盤空間不能正常釋放）。這時查看slave的主從狀態，發現sql線程有異常，如下圖：
解決：記得該庫下有200多張表，由於庫已刪，當時查詢表數量的sql結果也不在了，所以具體有多少張表已無法核實，如果用STOP SLAVE;>SET GLOBAL SQL_SLAVE_SKIP_COUNTER=N;>START SLAVE;的方法跳過該錯誤肯定不合適，一個一個的跳過太慢了；批量跳過又有導致主從數據不一致的風險，假如有280張表，而你不知道具體表數量，如果跳過了281個，那恰巧第281個是一個嚴重需要解決的sql錯誤，那這時被跳過了就會導致主從數據不一致，為業務埋下隱患。所以在別人的提示下用如下方法解決，參考鏈接https://www.cnblogs.com/gomysql/p/4991197.html：
知識點擴展：
處理該錯誤的方法還有如下面一種方法，但我在這里未實際驗證，所以只說方法。
1.方法：查看上面的第一張圖，可以看到錯誤提示碼為1146，在slave的my.cnf的[mysqld]段添加slave_skip_errors=1146,然后重啟slave數據庫，主從關系即可恢復正常。
2.還有人提出使用該方法處理的，但我認為該方法不可取，稍后說原因。方法：在master上用mysqlbinlog命令查看相關的binlog日志，然后用相關的pos點在slave上通過STOP SLAVE;>CHANGE MASTER TO MASTER_USER='XXX' ,MASTER_PASSWORD='XXX',MASTER_HOST='XXX',MASTER_PORT='XXX',MASTER_LOG_FILE='XXX',MASTER_LOG_POS='XXX';>START SLAVE;語句進行恢復。該方法不可取的原因是因為該實例下還有別的庫，其他庫在你刪除200多張表的時間內也是在進行sql操作的，這樣移動pos點就將這中間其他庫穿插操作的sql也忽略了，這樣就造成了主從不一致。從上圖可以看出該庫該類型錯誤的開始POS點是279231717，而該庫該類型的最后一條執行語句的結束POS點是279910383，中間穿插其他庫語句的POS點是279910182，綜上所述該方法不可取。POS點見下圖：
