临时表不会降低InnoDB行锁或间隙锁的竞争强度；它仅是会话级私有容器，不参与MVCC、不写undo log，对锁争用无分流作用。
临时表本身不缓解事务锁竞争
直接说结论：显式创建 CREATE TEMPORARY TABLE 或依赖优化器隐式生成的内部临时表，**不会降低 InnoDB 行锁或间隙锁的竞争强度**。临时表是会话级私有结构，它不参与主表的 MVCC 版本链、不写 undo log、也不被其他事务感知——但它对锁争用毫无“分流”作用。
常见误解是：“把 JOIN 中间结果先塞进临时表，就能避开大表上的锁”。实际执行时，只要 SQL 里还涉及对业务表（如 orders、users）的 UPDATE/SELECT FOR UPDATE，锁依然照常加在那些行或间隙上。临时表只是后续计算的容器，不是锁的避风港。
哪些场景下误以为临时表“起了作用”
你可能观察到加了临时表后整体耗时下降，于是归因于“锁减少了”。更大概率的真实原因是：
- 拆分复杂查询后，单条语句执行时间变短 → 锁持有时间缩短 → 其他事务等待窗口收窄
- 原查询因内存不足频繁落盘（
Created_tmp_disk_tables高），改用临时表后稳定走内存（internal_tmp_mem_storage_engine = 'TempTable'），I/O 等待减少，掩盖了锁等待 - 原本一个长事务包揽多张表更新，改成先 SELECT INTO 临时表 + 分批 UPDATE，客观上把大事务切成了多个小事务，降低了锁升级概率
注意：这属于事务拆分策略的收益，和临时表这个载体无关——换成普通表、CTE 甚至应用层缓存，效果一致。
真正能降低锁竞争的替代做法
如果目标是减少多表事务中的锁冲突，优先考虑这些实操路径：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确保所有
WHERE和JOIN条件都命中索引，避免行锁升级为表锁或间隙锁范围扩大 - 用
SELECT ... FOR UPDATE时，只锁定真正需要修改的行，避免SELECT * FROM t WHERE status = 'pending' FOR UPDATE这类无精度过滤的操作 - 批量更新改用主键 IN 列表（
UPDATE t SET x=1 WHERE id IN (1,2,3,...)），比范围扫描更可控 - 高并发写入场景下，把
AUTO_INCREMENT主键替换为UUID或雪花 ID（需权衡二级索引碎片） - 检查隔离级别：若业务允许，将
REPEATABLE-READ改为READ-COMMITTED，可消除大部分间隙锁
临时表在这里最多是个辅助工具，比如用来预存一批主键 ID 再分批处理，但它不改变锁的本质行为。
临时表反而可能加剧锁问题的坑
尤其当业务混合使用 MyISAM 和 InnoDB 时：
- MyISAM 表本身是表级锁，你在事务里对 MyISAM 表做任何写操作，整个表就锁死；此时建再多临时表也无济于事
- 盲目调大
max_heap_table_size，导致复杂查询在内存中跑得更久，反而延长了对 MyISAM 表的持有时间 - 临时表若定义为
ENGINE=InnoDB（显式指定），它会参与事务，一旦出错回滚，也会拖慢主事务提交
最易被忽略的一点：临时表的元数据操作（如 DROP TEMPORARY TABLE）在某些 MySQL 8.0.x 版本中会触发 MDL 锁等待，若与长事务或 DDL 交叉，可能引发连锁阻塞——这不是数据锁，但一样卡住整个会话。
