MySQL 複制中臨時表避坑指南：SQL_LOG_BIN 關鍵技巧

臨時表三大特性

1. 會話級：斷開自動 DROP
2. 引擎綁定：默認引擎決定存儲引擎，InnoDB 會膨脹 ibdata
3. 寫 Binlog：默認記錄，從庫重放會創建同名臨時表

災難場景：Binlog 重放失敗

# 主庫操作
CREATE TEMPORARY TABLE tmp_x AS SELECT * FROM big_table;
UPDATE tmp_x, tmp_y SET ...;
DROP TEMPORARY TABLE tmp_x, tmp_y;

問題：Binlog 記錄了 CREATE TEMPORARY TABLE，從庫重放時：

• 若中間斷點恢復，會話已斷 → 臨時表不存在 → UPDATE 報錯
• 並行複制下，臨時表名衝突

正確姿勢：關閉會話級 Binlog

SET SESSION SQL_LOG_BIN = 0;  -- 僅影響當前連接

CREATE TEMPORARY TABLE tmp_x ...;
UPDATE tmp_x, tmp_y ...;
DROP TEMPORARY TABLE tmp_x, tmp_y;

SET SESSION SQL_LOG_BIN = 1;  -- 恢復

為什麼不用 binlog_format=ROW？

Row 格式記錄行變更，不記錄 CREATE TEMPORARY TABLE，但：

• 臨時表 DDL 仍以 Statement 寫入
• 大事務 Row 模式 Binlog 膨脹
• 不解決會話斷開導致臨時表消失的根本問題

生產規範建議

1. 應用代碼中，臨時表操作前後包裹 SQL_LOG_BIN=0/1
2. 監控 Binlog 中 CREATE TEMPORARY TABLE 頻率，異常報警
3. 避免在長事務/跨會話流程使用臨時表
4. 考慮用 WITH (CTE) 或 內存表替代（MySQL 8.0+）

擴展：replicate-wild-ignore-table 不生效

過濾規則不匹配臨時表（臨時表不在 information_schema.TABLES 中），只能靠 SQL_LOG_BIN 控制。