临时表不是自动加速器，而是显式资源申请：每次创建均触发解析、内存/磁盘预留与锁获取，高并发下开销显著；字段类型不匹配会静默截断，无索引易致全表扫描；engine=memory遇text/blob或超宽字段强制落盘；tmp_table_size与max_heap_table_size取较小值决定内存上限，需同步调优；join生效前提为临时表作驱动表+目标表字段有索引+使用inner join；tmpdir路径权限与引擎配置（如internal_tmp_mem_storage_engine=temptable）错误将使所有优化失效。
临时表不是“自动加速器”，而是显式资源申请
MySQL 存储过程中显式创建 CREATE TEMPORARY TABLE，不等于性能提升——它本质是一次同步的、阻塞式的资源分配操作。每次执行都会触发表结构解析、内存/磁盘空间预留、锁获取（哪怕只在会话内），这些开销在高并发调用下会被显著放大。
常见错误现象包括：存储过程响应时间不稳定、SHOW PROCESSLIST 中频繁出现 Creating tmp table 状态、QPS 上升时 CPU 使用率陡增但吞吐未线性增长。
- 临时表字段类型若与插入数据不匹配（如源是
VARCHAR(200)，目标表定义为VARCHAR(50)），MySQL 会静默截断或隐式转换，可能引发后续 JOIN 或 WHERE 条件失效 - 未加主键或索引的临时表，在后续
JOIN或WHERE查询中极易退化为全表扫描，尤其当行数超 1 万后，性能断崖式下跌 - 使用
ENGINE=MEMORY时，若实际数据含TEXT/BLOB或单行超宽（如CONCAT()推导出超长VARCHAR），MySQL 会直接强制落盘，且不报错——你看到的只是变慢，而不是报错
tmp_table_size 和 max_heap_table_size 不一致会立即失效
这两个参数共同决定单个临时表能否留在内存里。MySQL 实际取二者中的较小值作为上限，而非求和或取最大。设成 tmp_table_size = 256M、max_heap_table_size = 64M，结果就是所有临时表只要超 64MB 就落盘。
更隐蔽的问题是：该限制是 per-session 的。200 并发连接 × 64MB = 理论峰值 12.8GB 内存占用——如果服务器总内存只有 32GB，很容易因内存争抢触发 swap 或 OOM。
- 确认当前值：
SELECT @@tmp_table_size, @@max_heap_table_size; - 生产环境建议从
128M起步，上线后紧盯SHOW STATUS LIKE 'Created_tmp_disk_tables';每秒增量；若 > 1，再小幅上调 - MySQL 8.0+ 必须设
internal_tmp_mem_storage_engine = TempTable，否则MEMORY引擎的固定行格式和不支持TEXT会持续制造陷阱
临时表 + JOIN 不等于优化，驱动顺序和索引缺一不可
把 IN 列表转成临时表再 JOIN，只是第一步。真正起效的前提是：优化器必须选择以临时表为驱动表，并且目标表关联字段有可用索引。否则仍是嵌套循环 + 全表扫描。
典型翻车场景：目标表 id 字段没索引，或临时表没主键，或 JOIN 写成 SELECT * FROM target t LEFT JOIN tmp_ids i ON t.id = i.id（LEFT JOIN 让优化器放弃驱动表控制权）。
- 临时表务必带主键：
CREATE TEMPORARY TABLE tmp_ids (id BIGINT UNSIGNED PRIMARY KEY) -
JOIN必须用INNER JOIN，并确保写法为SELECT t.* FROM target_table t INNER JOIN tmp_ids i ON t.id = i.id - 目标表字段必须已有索引：
ALTER TABLE target_table ADD INDEX idx_id (id)，否则 JOIN 无意义 - 批量插入 ID 时，每批 ≤ 1000 行，避免单条
INSERT造成大量 round-trip 开销
tmpdir 配置错误会让所有优化归零
即使你把 tmp_table_size 调到 1G、用上 TempTable 引擎，只要 tmpdir 还指向默认的 /tmp 或 NFS 挂载点，磁盘 I/O 就会成为最终瓶颈。MySQL 对 tmpdir 路径极其挑剔，配置错误往往静默 fallback，不报错也不提示。
- 检查是否生效：
SELECT @@tmpdir;，必须返回你预期的绝对路径（不能是符号链接） - 路径权限需满足 MySQL 进程用户（如
mysql）对整个路径有rwx权限，包括所有父目录 - SELinux 启用时，必须打标：
chcon -t mysqld_tmp_t /mnt/ssd/mysql-tmp - 理想路径是单独挂载的 NVMe 分区（如
/mnt/nvme/mysql-tmp），与datadir和innodb_temp_data_file_path物理隔离
临时表本身不慢，慢的是没控制住它的资源边界、没约束住它的访问路径、也没管住它被怎么使用。最容易被忽略的，其实是 tmpdir 权限和 internal_tmp_mem_storage_engine 这两个看似“配好了就行”的配置项——它们一旦出问题，所有上层 SQL 优化都白做。
