临时表本身不复制，但用法不当会导致主从不一致：CREATE TEMPORARY TABLE不写binlog，若后续INSERT/UPDATE依赖该临时表，从库因缺失表而报错1146；STATEMENT模式下存储过程内使用临时表会因会话隔离失败；ROW模式下若临时表数据含非确定性函数，主从内容仍可能不同。
临时表本身不会导致主从不一致，但用法不当会——关键在是否被写入 binlog 以及从库能否复现相同上下文。
为什么 CREATE TEMPORARY TABLE 在主从间容易出问题
MySQL 的 CREATE TEMPORARY TABLE 语句默认不写入 binlog（无论 binlog_format 是 ROW 还是 STATEMENT），这是设计使然：临时表只对当前会话可见，生命周期随会话结束自动销毁，从库没必要、也无法同步它。
但问题常出现在后续操作中：
- 主库用临时表做中间计算，再
INSERT INTO real_table SELECT ... FROM tmp_table—— 这条INSERT会被记录到 binlog，但从库执行时tmp_table不存在，直接报错Error_code: 1146 Table 'xxx.tmp_table' doesn't exist - 主库在存储过程中创建临时表并多次读写，过程被记录为 STATEMENT 格式，从库回放时因会话隔离无法访问同名临时表，或因执行顺序/并发导致数据错乱
- 使用
log_bin_trust_function_creators = 0时，含临时表的自定义函数在从库创建失败，导致调用时报错ERROR 1418，进而阻断复制
如何安全地在复制环境中使用临时表
核心原则：**临时表必须完全在单个会话内闭环，且所有依赖它的 DML 必须可重入、无外部状态依赖。**
- 避免跨语句依赖：不要在 A 会话建
tmp_a，再在 B 会话里SELECT FROM tmp_a—— 主库可能因连接池复用“看似成功”，但从库严格按会话隔离，必然失败 - 改用普通表 + 命名空间隔离：如需中间结果，建带时间戳或线程 ID 后缀的普通表（
staging_orders_20261013_12345），显式DROP，确保 binlog 完整记录建表与删表 - STATEMENT 模式下禁用临时表参与 UPDATE/DELETE 的 WHERE 条件：例如
UPDATE t SET x=1 WHERE id IN (SELECT id FROM tmp_ids)在从库会因tmp_ids不存在而全表更新或报错 - ROW 模式也不能高枕无忧：虽然 DML 被逐行记录，但如果临时表数据来自非确定性源（如
NOW()、RAND()），主从插入的行内容仍可能不同
已经出错了怎么办：跳过还是重建
出现 1146 或 1418 错误时，不能简单 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 —— 这会跳过整个事务，可能导致后续依赖该临时表结果的 DML 也丢失。
- 先确认错误是否由临时表引起：在从库执行
SHOW BINLOG EVENTS IN 'mysql-bin.000001' FROM XXX LIMIT 10，看报错位置前是否有CREATE TEMPORARY TABLE或涉及临时表名的语句 - 若只是单次误用，且业务允许短暂不一致：停复制 → 在从库手动建同结构普通表 → 手动补数据 → 改写原 SQL 中的临时表名为该普通表 → 启动复制
- 若已扩散多张表或多事务：用
pt-table-checksum全量校验，再用pt-table-sync --sync-to-master --print预览修复语句；发现大量1146相关错误时，说明架构层已不可靠，应推动将临时表逻辑重构为幂等普通表流程
真正难处理的不是临时表本身，而是那些隐式依赖会话状态、又混在复杂存储过程里的临时表调用——它们在主库跑得通，在从库静默失败或错位执行，直到某天业务对账才暴露。所以，上线前务必在从库开启 read_only = ON 并用真实流量压测复制链路。
