一、背景
突然發現每天中午以及下午的延時變高，檢視主從的延時經常達到10分鐘以上，整體使用的是mysql-proxy實現的讀寫分離機制，所以業務的影響主要是插入資料後久久不能查詢到資料。
由於使用mysql業務比較多，一時之間不能快速定位，導致該問題存在的較長時間。
二、解決思路
1.到了案發時間，下午16點半，直接登陸從庫檢視程序情況，查詢耗時較長的資料表&語句
2.定位到查詢語句，檢視表結構+表的數量，發現存在三個問題：
(1)使用的myisam引擎
(2)表中資料達到500w+，存放的是使用者操作記錄，最早的資料是2018-10的，即大量無用資料
(3)未命中索引，進行全表查詢
3.解決方案：
(1)清理年代久遠的資料，只保留近3個月的操作記錄，資料量一下減少到30w左右
(2)將引擎修改為innodb，將原本的表級鎖改為行級鎖
(3)優化查詢語句，充分利用索引
4.驗證
執行查詢語句的定時指令碼，指令碼迅速跑完，主從延時不超過5s，可以證明該問題已經解決。
三、刨根問底
問題確實解決了，主要原因就是引擎&查詢語句導致的耗時較長，但是令人疑惑：
按理說myisam鎖表也就鎖這一張表呀，為啥會導致大量業務也有問題了呢？
通過查詢資料終於找到了結果：
(1)使用的是mysql-proxy的讀寫分離功能，寫是寫到主庫，讀是查詢從庫，主庫要定時同步到從庫
(3)由於是需要順序執行，所以查詢語句導致的鎖表就會堵塞住寫入操作，進而使整體的主從延時嚴重
(水落石出)
四、反思
其實當時解決這個問題後就沒去細想了，後來跟其他人講起這個事情，詳細深入的**，發現邏輯不太通，被問得啞口無言，所以才有後面的刨根問底，挺感慨的，表面上好像懂了，其實並不完全懂。後面要避免這種情況。
mysql排查指南 mysql出錯排查
1,例如 can t connect to local mysql server through socket tmp mysql 5.5.37.sock 2 mysql鏈結出錯，請配置 amysql config.php檔案。解決 config.php位置是 usr local amh 5.0 w...
排查mysql響應慢 MySQL反應慢排查思路
資料庫異常假死排查需要資料 當時問題的時間，前後時間在2個小時的資料就行 1.mysql相關配置 整體可以借助於pt mysql summary生成 percona tools工具 2.作業系統方面 var log message 核心日誌 硬體基本資訊，可以借助於pt summary資訊 perc...
MySQL死鎖排查
答 1 檢視當前事務中是否有鎖資訊 select trx id,trx state,trx started,trx requested lock id,trx weight from innodb trx 2 檢視鎖資訊 表鎖or行鎖，鎖的那張表 select lock id,lock trx id...