一、MySQL 連接檢測（CONNECT 方式）

定義：通過建立 MySQL TCP 連接的方式檢測主庫是否存活：嘗試連接主庫的 3306 端口，若連接成功則認為主庫存活，否則判定故障。（典型工具：MHA 的ping_type=CONNECT、mysql客户端、編程語言的 MySQL 連接庫）。

實現邏輯：

優點：

1. 直接檢測 MySQL 服務可用性：若 MySQL 進程宕機，連接會直接失敗（精準區分 “服務器活但 MySQL 死” 的場景）；
2. 實現簡單：無需複雜邏輯，僅依賴 TCP 連接能力；
3. 低權限要求：只需 MySQL 的 “連接權限”（無需執行 SQL 的權限）。

缺點：

1. 易誤判：網絡波動、臨時連接隊列佔滿會導致連接超時，但 MySQL 實際存活；
2. 檢測深度不足：若 MySQL 進程存活但 “服務不可用”（如死鎖、資源耗盡卡住），連接能建立但業務無法訪問，此方式無法檢測；
3. 超時配置敏感：超時時間過短易誤判，過長則故障發現延遲高。

二、SQL 執行檢測（SELECT 方式）

定義：在成功建立 MySQL 連接後，執行輕量 SQL 語句（如SELECT 1），若能正常返回結果則認為主庫存活。（典型工具：MHA 的ping_type=SELECT、監控工具的 “SQL 心跳”）

# 示例：執行SELECT 1檢測
mysql -h 192.168.10.112 -P 3306 -u admin -ppass -e "SELECT 1;"
# 若返回結果則存活，否則故障

優點：

1. 檢測更深入：不僅驗證 “連接是否通”，還驗證 MySQL 能否正常處理請求（避免 “連接成功但服務卡住” 的情況）；
2. 開銷極小：SELECT 1是 MySQL 最輕量的 SQL 之一，對主庫性能幾乎無影響。

缺點：

1. 需要 SQL 權限：需 MySQL 用户具備SELECT權限（比單純連接權限要求高）；
2. 仍有漏判場景：若 MySQL 處於 “只讀狀態”“表鎖狀態”，SELECT 1能返回但業務寫入不可用，此方式無法檢測；
3. 受網絡 / MySQL 負載影響：網絡延遲或 MySQL 高負載會導致 SQL 執行超時，誤判為故障。

三、INSERT 心跳檢測

定義：通過執行輕量、原子性的寫入操作（基於獨立心跳錶），驗證主庫 “全鏈路業務可用性”（網絡層 + 連接層 + 事務層 + 存儲引擎層）的檢測方式。若 INSERT 操作能正常執行（含提交 / 更新），則認為主庫業務可用；若超時 / 報錯，則判定主庫故障。（典型場景：搭配 MHA 自定義檢測腳本、核心業務主庫的高可用檢測）

實現邏輯：

編輯

優點：

1. 檢測深度貼近業務實際：不僅驗證 “連接通”，還覆蓋主庫的寫入能力、事務提交、存儲引擎可用性，能精準識別 “連接通但寫阻塞” 的假活場景（如死鎖、MDL 鎖、磁盤滿）；
2. 覆蓋更多故障場景：可檢測 CONNECT/SELECT 1 無法識別的問題（如主庫只讀、InnoDB 表損壞、Binlog 寫入失敗）；
3. 無業務侵入風險：基於獨立心跳錶（非業務表），原子性操作（更新而非新增）不會污染業務數據，對主庫性能影響極小。

缺點:

1. 存在輕微性能開銷：INSERT 涉及事務、日誌寫入等操作，高頻率檢測（如每秒 1 次）會產生少量 Binlog/IO 開銷；
2. 需額外維護心跳錶：需手動創建 / 監控獨立心跳錶，且需為檢測用户授予心跳錶的INSERT/UPDATE權限，增加運維成本；
3. 可能因業務壓力誤判：主庫突發高併發時，心跳 INSERT 可能因排隊延遲超時，導致 “主庫正常但檢測失敗” 的誤判；
4. 依賴心跳錶狀態：若心跳錶自身損壞（如表空間異常），會導致檢測結果失真，需額外監控心跳錶健康度。

四、SSH 心跳檢測

定義：通過SSH 連接到主庫所在服務器，執行系統級命令（如檢查 MySQL 進程、端口監聽狀態），間接判斷主庫是否存活。（典型工具：MHA 的 SSH 健康檢查、自定義 Shell 腳本）

實現邏輯：

# 示例：SSH到主庫服務器，檢查mysqld進程
ssh root@192.168.10.112  "ps -ef | grep mysqld | grep -v grep"
# 若返回進程信息則認為MySQL存活

優點：

1. 覆蓋系統層面故障：能區分 “服務器宕機”（SSH 連不上）和 “MySQL 進程死但服務器活”（SSH 能連但進程不存在）；
2. 可擴展檢測維度：可同時檢測服務器資源（如磁盤空間、內存使用率），提前發現潛在故障。

缺點：

1. 安全風險高：需要 SSH 免密登錄權限（若 SSH 密鑰泄露，服務器會被非法訪問）；
2. 檢測深度不足：僅能驗證 “MySQL 進程存在”，無法檢測進程是否能正常處理業務請求（如進程僵死）；
3. 開銷較大：SSH 連接的資源開銷遠高於 MySQL 連接 / SQL 執行。

五、TCP 端口監聽檢測

定義：通過檢測主庫 3306 端口是否處於 “監聽狀態”（即 TCP 三次握手能否完成），判斷主庫是否存活。（典型工具：telnet、nc（netcat）、監控工具的端口檢測）

實現邏輯：

# 示例：用nc檢測3306端口
nc -z -w 2 192.168.10.112 3306
# 若返回0則端口監聽，非0則未監聽

優點：

1. 極致輕量：僅檢測 TCP 端口狀態，資源開銷可忽略；
2. 實現簡單：無需 MySQL 權限，僅依賴網絡端口可達性。

缺點：

1. 誤判率極高：端口監聽≠MySQL 服務可用（如 MySQL 剛啓動還在加載數據、進程僵死但端口未釋放）；其他進程可能佔用 3306 端口（導致誤判為 MySQL 存活）；
2. 無服務級檢測：完全無法驗證 MySQL 的業務處理能力。

六、外部監控工具綜合檢測

定義：通過專業監控工具（如 Zabbix、Nagios、Prometheus），組合多種檢測方式（端口、連接、SQL、系統資源），並結合 “二次確認” 邏輯判斷主庫存活。（典型場景：MHA 的secondary_check_script（多節點二次確認）、Keepalived + 自定義檢測腳本）

實現邏輯：

# 從2個從庫節點二次確認主庫是否存活
masterha_secondary_check -s 192.168.10.115 -s 192.168.10.116

優點:

1. 低誤判率：組合多種檢測方式 + 多節點二次確認，避免單點網絡 / 節點故障導致的誤判；
2. 檢測維度全面：可同時覆蓋 “網絡、服務、系統資源”，提前發現潛在風險；
3. 支持告警 / 自動處理：故障時可觸發告警（微信 / 郵件），並聯動高可用工具執行切換。

缺點：

1. 部署維護複雜：需配置監控工具、自定義檢測腳本，對運維能力要求高；
2. 資源開銷較大：多維度檢測會佔用一定的服務器 / 網絡資源；
3. 依賴監控工具可用性：若監控工具自身故障，檢測能力會失效。

七、業務級檢測

定義：執行實際業務場景的 SQL（如查詢基礎業務表、寫入測試數據後刪除），驗證主庫是否能正常處理業務請求。

實現邏輯：

# 示例：查詢業務表+寫入測試數據（原子性刪除）
mysql -h 192.168.10.112 -P 3306 -u user -ppass -e "
SELECT COUNT(*) FROM user_info LIMIT 1;
INSERT INTO test_heartbeat (id) VALUES (1) ON DUPLICATE KEY UPDATE id=1;
DELETE FROM test_heartbeat WHERE id=1;
"

優點：

1. 最貼近業務實際：直接驗證主庫能否支撐業務，避免 “服務存活但業務不可用” 的情況。

缺點：

1. 性能開銷大：寫入操作會佔用主庫資源（尤其是高併發場景）；
2. 實現複雜：需處理業務表的權限、數據一致性（如測試數據需原子性清理）；
3. 風險高：若檢測邏輯出錯（如測試數據未刪除），會污染業務數據。

各檢測方式的適用場景總結