大表更改字段問題

故障描述：

客戶端各處接口請求失敗

故障過程

• 晚上6點(diǎn)開始報(bào)警
• 回滾access新上線代碼， 繼續(xù)報(bào)警
• 發(fā)現(xiàn)數(shù)據(jù)庫db02機(jī)器響應(yīng)異常
• 45分dba確認(rèn)在該機(jī)器上業(yè)務(wù)的query 等待mdl (這個需要去了解一下是啥)，kill掉sleep的query后服務(wù)恢復(fù)

故障分析

• 6點(diǎn)的時(shí)候?qū)Ω枨恚ㄒ粋€4000w量級， 字段也很多的表進(jìn)行了 該表操作， 新增了一個字段）
• 該操作同步到從庫02機(jī)器后, 被慢查block， 整個block鏈路， 慢查block了改表的mdl, mdl又block了其他的查詢， 其他的查詢又block住了tornado服務(wù)

因?yàn)闉榱丝焖倩謴?fù)服務(wù)， dba kill掉sleep的query操作， 無法查找具體的慢查詢sql

推測：

確認(rèn)改表引起的mdl為表級鎖， 所以慢查肯定是發(fā)生在mi_song表。 并且我們使用了miproxy(小米的連接數(shù)據(jù)庫的一個代理) miproxy在路由請求時(shí)會把事務(wù)都路由在主庫上， 所以這次慢查詢時(shí)沒有顯氏開啟事務(wù)的， 另外查詢都是通過music_access項(xiàng)目創(chuàng)建出來的對象， 該對象默認(rèn)時(shí)開啟事務(wù)， 所以排除這個項(xiàng)目引起次忙查。 其他可能的忙查源自人工操作， 或者數(shù)據(jù)工廠
（感覺這個結(jié)論有問題）