問題描述：
程序上表現爲對 主庫 更新操作之後，從 從庫 查詢數據沒發生改變。懷疑是主從庫同步延遲導致。上從庫查看主從同步狀態，發現Seconds_Behind_Master時間長達一千多秒。正常情況下主從庫延時個十幾秒還可以容忍，一千多秒顯然就有問題了麼。。。
問題分析：
我們在一個MYSQL實例上創建了四五個Database，其中一個Database數據量和壓力都比較大，從 從庫的processlist可以看到從庫在處理日誌時經常發生lock的狀況，但是lock只是壓力大database爲何會影響到其他database也延遲呢？
原來從庫是單線程處理同步日誌，也就是說無論多少個database都是通過一個線程去執行更新操作，所以主從庫同步延遲的時間不是針對database的，是針對一個MYSQL實例的。
那麼，爲何從庫在處理日誌時會發生lock的狀態呢？
一般我們都將主從庫讀寫分離，主庫負責寫操作，從庫負責讀操作。而一般的web應用讀數據的操作要遠遠大於寫數據的量，所以我們在主庫上幾乎看不到因爲更新數據導致的lock。那麼從庫的lock怎麼發生的呢？
1.對MyISAM表的讀操作（加讀鎖），不會阻塞其他進程對同一表的讀請求，但會阻塞對同一表的寫請求。只有當讀鎖釋放後，纔會執行其它進程的寫操作。
2.對MyISAM表的寫操作（加寫鎖），會阻塞其他進程對同一表的讀和寫操作，只有當寫鎖釋放後，纔會執行其它進程的讀寫操作。
從上面可以看出，我們在select的時候默認是會阻塞寫請求的，當一個表數據量到達了千萬級別，那麼執行一個select很有可能就會變得比較費勁，再加上一定的壓力，不斷地select操作，雖然讀數據不會受到影響，但是卻阻塞了從庫處理同步日誌的操作。長此以往。。。可想而知。。。
問題處理：
1.首先一個MYSQL實例不要創建太多database，否則一旦其中一個庫壓力大經常被鎖，會導致所有庫同步都延遲，你傷不起啊。。。
2.壓力較大的情況下使用幾個從庫值得考量，如果使用多個從庫也是可以適當緩解上面lock的情況發生。