MySQL 運維日誌：MHA 故障切換、Event 復制陷阱與深分頁優化實戰

MySQL 運維日誌：核心場景實戰複盤

記錄生產環境高可用切換、Event 復制行為差異、深分頁 SQL 優化等實戰案例，供同類問題快速參考。

案例一：MHA 修復宕機主庫並重新納入集群

現象

主庫宕機，MHA 自動將候選從庫提升為新主，原主庫重啟後 SHOW SLAVE STATUS 為空。

修復步驟

1. 查看 MHA 日志確認 CHANGE MASTER TO 命令：
   grep "All other slaves should start" /var/log/manager.log
2. 在原主庫執行該 CHANGE MASTER TO MASTER_HOST='new_master' ... 指向新主。
3. START SLAVE; 啟動復制線程。
4. SET GLOBAL read_only=1; 設為只讀，防止誤寫入。
5. 檢查 Seconds_Behind_Master=0 後，刪除 app1.failover.complete 允許 MHA 再次監控。
6. 執行 SET GLOBAL relay_log_purge=0; 防止中繼日志被過早清理。

案例二：Event 復制狀態 SLAVESIDE_DISABLED 導致切換後事件不執行

背景

主庫 ALTER EVENT ... ENABLE 不會同步到從庫，從庫事件保持 SLAVESIDE_DISABLED。切換後新主庫事件仍處於禁用狀態。

解決腳本

-- 生成所有庫的 EVENT 啟用語句
SELECT CONCAT('ALTER EVENT `', EVENT_SCHEMA, '`.`', EVENT_NAME, '` ENABLE;')
FROM information_schema.EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED';

在新主庫批量執行輸出語句，並納入切換後驗證清單。

案例三：深分頁優化 — 400 萬表 LIMIT 60000,20 從 2s 降至 50ms

表結構關鍵索引

KEY idx_2_qstatus_opstatus_sc_so (QuestionStatus, OperateStatus, Age, Score, Source)
KEY idx_2_ctime_qstatus_opstatus (CreateTime, QuestionStatus, OperateStatus, CatalogID, Age)

原始 SQL（全表掃描 + filesort）

EXPLAIN SELECT * FROM question_2
WHERE QuestionStatus >= 0 AND OperateStatus = 2 AND Age IN (1,2)
ORDER BY qid DESC LIMIT 60000,20;
-- type=ALL, rows=400萬, Using where; Using filesort

優化思路：延遲關聯

1. 先在覆蓋索引上只取主鍵 qid（避免回表）。
2. 再用主鍵關聯回原表取全字段。

EXPLAIN SELECT * FROM question_2
INNER JOIN (
    SELECT qid FROM question_2
    WHERE QuestionStatus >= 0 AND OperateStatus = 2 AND Age IN (1,2)
    ORDER BY qid DESC LIMIT 60000,20
) a USING (qid);
-- 內層：type=ref, rows≈360萬, Using index; 外層：eq_ref, rows=1

效果對比

適用條件

• 有合適的複合索引覆蓋 WHERE + ORDER BY 列。
• 主鍵為自增或有序，ORDER BY pk DESC 可利用索引逆序掃描。

總結

運維核心在於「預案先行、腳本自動化、變更可回滾」。MHA 切換後必須驗證 Event 狀態、read_only、復制延遲；深分頁優化首選「延遲關聯」或「游標分頁」。