一個不是很大的表，由數據分析部門生成並用於業務。由於代碼發了新版需要第一次運行，所以在業務低峰期讓數據部門執行了，邏輯是先truncate再insert重建。由於一直以來都沒問題，覺得不會出錯。結果過一會兒悲劇了，告警來了，app首頁空白。。。
這種牽一發而動全局的故障，基本都是mysql引起。先看現象：
- cpu不高，很平穩
- 慢查詢正常
- 連接數很高
這種很可能是鎖表。進去一看processlist果然，那個truncate卡在那里，然后一堆線程在wating for meta data lock... kill后故障恢復，數據表改由delete清空
由這個例子講一下：
- 鎖表或db hang的一個顯著表現就是connection飆升，這是由於連接池的行為，查詢無法返回就新開連接重查。嚴重時可以耗盡connection limit
- truncate應慎重，它屬於ddl，會lock table meta data，甚至可能由鎖表升級為鎖庫
- 業務錯綜復雜，首頁的推薦居然依賴數據分析...... 所以有了開頭那個app空白的尷尬。相關人當然已經被懟啦，哈哈