MySQL DBA 變更管理規範：從數據訂正到架構變更的分級管控體系

變更分級定義

一、數據訂正類變更

1.1 大數據量核心表訂正 (→ 重大變更)

• 表行數 ≥ 100 萬
• 屬於核心業務表 (訂單、用戶、交易等)
• 訂正行數佔表總量 ≥ 1%
• 目標列修改頻繁 (熱點數據)

應對： 分批次 (每批 5000–10000 行)、pt-online-schema-change 模式、配合 WHERE pk BETWEEN ... 範圍提交、每批 SLEEP(0.1) 降壓。

1.2 大表有索引可走 (→ 一般變更)

• 訂正行數 < 1% 總量
• WHERE 條件命中高選擇性索引 (EXPLAIN type=ref/range)

驗證： 先 SELECT 確認影響行數與預期一致，再執行 UPDATE。

1.3 大表無索引可走 (→ 重大變更)

• 表行數 > 50 萬
• 核心表 或 熱點修改列
• 全表掃描鎖表風險極高

應對： 先低峰加索引 (在線 DDL/OSC) → 走索引訂正 → 再評估是否保留索引。

1.4 數據導入

二、數據庫結構變更 (DDL)

2.1 新建表對象 (→ 一般變更)

無數據遷移風險，僅創建對象。需審核：命名規範、引擎選擇 (InnoDB)、字符集 (utf8mb4)、主鍵設計、索引合理性。

2.2 修改表結構 (→ 重大變更)

觸發條件： 表數據文件 > 500MB 且執行以下操作：

• 修改列名 / 刪除列 / 新增列
• 修改列屬性 (類型、長度、NULL/NOT NULL、默認值)
• 修改自增值起始位置

執行策略：

1. 優先使用 Online DDL (5.6+)：ALGORITHM=INPLACE, LOCK=NONE
2. 不支持 Inplace 時：pt-online-schema-change (OSC) 或 gh-ost (無觸發器、可暫停、可限流)
3. 極大表 (TB 級) 必須走 gh-ost，預演於從庫，驗證無誤後主庫執行

2.3 索引變更 (→ 視情況定級)

• 表 > 500MB 且 高併發寫入/極低延遲要求 → 重大變更
• 其他 → 一般變更

黃金法則： 先加新索引，驗證生效 (EXPLAIN)，再刪舊索引。避免瞬間無索引導致全表掃描風暴。

2.4 其他操作分級表

三、服務端參數變更

3.1 動態只讀變量 (SET GLOBAL 生效)

• 如 max_connections、innodb_buffer_pool_size (5.7+ 支持在線擴容)
• 統一按重大變更管理，增加審核嚴肅性
• 執行前 SHOW VARIABLES 留存，執行後驗證 SHOW GLOBAL VARIABLES

3.2 靜態只讀變量 (需修改 my.cnf + 重啟)

• 如 innodb_log_file_size、innodb_page_size、lower_case_table_names
• 必須重大變更，涉及服務重啟
• 非緊急情況：納入半年期主機維護窗口
• 緊急情況：評估業務影響、獲取應用方書面確認、制定回滾預案 (備份舊配置、測試啟動腳本)

四、ITIL 流程整合

4.1 應用方發起變更

• 提交變更單：SQL 腳本、影響範圍、回滾腳本、預計耗時、負責人
• DBA 評估：按本規範定級、審核 SQL 安全性 (無 SELECT *、無無索引 UPDATE/DELETE、大事務拆分)
• 定級分歧由技術負責人裁決

4.2 DBA 主動發起變更

• 索引優化：必須創建變更單，引用本規範 2.3 節定級
• 參數調優：只讀參數 → 重大變更 + 維護窗口；讀寫參數 → 重大變更 + 低峰執行
• 緊急優化 (如死鎖風暴)：走緊急變更流程，事後補單、複盤

五、變更執行標準化清單

1. 前置驗證： 從庫預演、EXPLAIN 驗證、影響行數確認、備份完成
2. 執行控制： 事務包裹 (DDL 除外)、分批提交、SLEEP 降壓、實時監控 (QPS、延遲、IO、鎖等待)
3. 異常處理： 遇錯誤立即停止、啟動回滾腳本、通知相關方、記錄時間線
4. 事後驗證： 數據核對 (行數、關鍵指標)、應用功能驗收、性能指標對比
5. 歸檔閉環： 變更單記錄：執行日志、耗時、問題、經驗教訓，更新 CMDB

六、工具鏈推薦

• OSC 工具： pt-online-schema-change (Percona)、gh-ost (GitHub)
• 審核平台： Yearning、Archery、SQLE (SQL 審核、回滾生成、執行編排)
• 變更管理： Jira + Confluence / 內部工單系統，關聯 CMDB
• 監控告警： Prometheus + Grafana + Alertmanager (關鍵指標閾值預置)

總結

MySQL 變更管理的核心是「風險分級、流程固化、工具賦能、事後複盤」。本規範將模糊經驗量化為可執行標準：500MB/50 萬行/1% 修改量 為關鍵分水嶺，Online DDL / OSC / gh-ost 為大表變更三板斧，半年期維護窗口 為靜態參數修改安全網。建議團隊根據業務成熟度持續迭代，引入自動化審核平台，將「人治」升級為「法治」，讓每一次變更都可控、可追溯、可復盤。