高可用核心指標 RTO (Recovery Time Objective)：故障切換耗時，目標 < 30 秒 RPO (Recovery Point Obje

優化維度總覽 硬件層 操作系統/庫 MySQL 服務器（配置與 SQL） API/連接器 應用程序 一、硬件選型與調優 CPU 大表（>2GB）優

全庫備份 tm_050519.sql.gz 恢復操作 # 前置：目標庫需存在 mysql -uroot -p -e CREATE DATABASE linu

核心錯誤代碼速查 錯誤碼訊息核心原因 1045Access denied for user密碼錯誤、Host 不匹配、權限未刷新 1130Host x.x.x

一、核心參數調優策略 參數作用調優建議 back_logTCP 連接請求隊列長度高併發連接場景調大（如 512），受 OS somaxconn 限制 join

服務管理 操作系統啟動停止重啟狀態 Windowsnet start MySQLnet stop MySQLnet restart MySQLsc query

查詢緩存工作原理 Key：SQL 文本逐字節 Hash（區分大小寫、空格、字符集） Value：完整結果集 失效：表任意 DML/DDL 觸發相關緩存全部失效

核心監控入口 SHOW GLOBAL STATUS; -- 運行時計數器 SHOW VARIABLES; -- 當前配置 SHOW

核心原理 MySQL 權限系統基於 user 表的 Host、User、Password 三元組匹配。默認 root@localhost 僅允許本地 Socke

架構動機 千萬級文檔全量重建索引耗時數小時，而日增量僅千條。採用「主索引 + 增量索引」雙層架構： 主索引：覆蓋歷史全量數據，每日零點重建 增量索引：覆蓋新增

工具定位 mysqldump 交互模式下執行** 位置：$MYSQL_HOME/bin/mysqldump（Windows/Linux 同名） 幫助：mysq

背景 MySQL 5.1/5.5/5.6 均無原生 ROWNUM 或 ROW_NUMBER()（8.0 才支持窗口函數）。常見替代方案： 測試數據準備 CRE

核心機制：Key-Value 精確匹配 Key 生成：SQL 文本按字節 Hash（區分大小寫、空格、註釋） Value：結果集完整副本 失效觸發：涉及表的任

一、命名與基礎規範 統一 InnoDB：事務、行鎖、崩潰恢復、聚簇索引優勢 小寫 + 下劃線：user_order、order_id 名稱極簡且語義清晰：sc

為什麼需要主從複製？ 讀寫分離：主庫寫、從庫讀，線性擴展查詢吞吐 備份卸載：從庫停止 SQL 線程冷備份，主庫零影響 災難恢復：主庫故障時提升從庫為新主 異構

場景：跨環境遷移存儲過程 本地開發庫結構已同步至目標 Linux MySQL，需僅遷移存儲過程/函數/事件，避免全量覆蓋。 核心命令 mysqldump -u

核心概念：InnoDB 的雙層數據字典 MySQL 將表結構定義存儲為 .frm 文件，這是所有存儲引擎通用的機制。但 InnoDB 還在表空間內部維護一套數據

實驗環境與目標 本次實驗在 MySQL 5.0.85 環境下進行，目標資料庫為 test，包含 sms 和 email 兩張表。實驗內容涵蓋完整庫備份、單表備份

一、連線相關 參數說明建議 max_connections最大連線數，每連線佔會話記憶體依應用峰值 + 余量 max_allowed_packet單次封包上限

問題現場 100 萬 URL 去重，需分頁載入記憶體。LIMIT offset, 500 隨著 offset 增大極慢： LIMIT 0,500 ~5ms L