前言：為什麼選 Binlog 而非 GTID？ MySQL 5.6 支持兩種復制模式： Binlog（傳統）： 成熟穩定，**支持臨時表**，生產首選 GTI

環境信息 OS：CentOS 6.5 MySQL：5.6（RPM 安裝） Master：192.168.17.140 Slave：192.168.17.141

一、表設計與存儲引擎 引擎選型： InnoDB 覆蓋 95% 場景（事務/行鎖/崩潰恢復），MyISAM 僅限只讀歸檔 拒絕全表掃描： WHERE/Order

一、復制原理三步走 Master 寫入 → 記錄 Binary Log (binlog) Slave I/O 線程 → 拉取 binlog → 寫入 Rela

現象：MySQL 啟動後秒退出，日志顯示 [Note] Plugin FEDERATED is disabled. [Note] MySQL: Normal s

錯誤現象 CREATE TABLE `gfan_content`.`channel_into` ( `time` INT(11) NOT NULL COMM

錯誤現象 [ERROR] Event Scheduler: Failed to open table mysql.event # 導致 MySQL 服務啟動失敗

方案一：Shell 精細控制（可見、可控、可審計） #!/bin/bash HOST=192.168.0.123 USER=xiaomo PWD=my_pwd

前言 MyISAM 表只讀、歸檔、日志類場景，**myisampack 可壓縮 40%-70% 空間**，但壓縮後表**只讀**，需配合 myisamchk 重

四大維護任務對照表 操作目的適用引擎SQL 語法命令行工具離線工具 OPTIMIZE碎片整理、回收空間、統計更新MyISAM, InnoDB, Archiv

場景：EXISTS 關聯子查詢慢 = 30000 AND table1.uuid = table2.uuid ); table1：10 萬行 table2：1

痛點：大 DELETE 鎖表、阻塞業務、主從延遲 -- 一條 SQL 刪 3 個月前數據，可能涉及百萬行 DELETE FROM messages WHERE

場景：查每組最小值對應的完整行 表 my_tbl(a, b, c)，需查每個 a 值下 b 最小的那行完整記錄。 -- 數據樣例 a | b | c 1 | 3

為優化查詢，開發者常在 VARCHAR 長字段上建立前綴索引（如 INDEX idx_name (col(8))）。但實測發現：雖查詢大幅加速，UPDATE 性

方案一：標準流程（需重啟，通用安全） 步驟 停庫： kill （禁用 kill -9，防數據損壞） 改配置： my.cnf [mysqld] 加 skip-

前言 二進制包（Generic Linux）部署 MySQL 最靈活、無依賴、適配性強。本文提供**參數化部署腳本**，支援單實例快速部署與多實例隔離部署，配置

場景：150 欄寬表，20 萬數據，深分頁超時 表 upay_csys_scquery_txn_log_his：150 個欄位，行長 ~2KB InnoDB

現象：從庫復制中斷，報主鍵衝突 SHOW SLAVE STATUS\G ... Last_SQL_Error: Could not execute Write

現象：幾萬行數據查 4-5 分鐘 Sphinx 從 MySQL 拉取源數據建索引，記錄數僅幾萬，但查詢耗時 4-5 分鐘。EXPLAIN 顯示索引用得不錯，無全

一、環境配置：讓 mysql/mysqldump 進入 PATH ~/.bashrc && source ~/.bashrc 二、命令行連接 MySQL