mysql临时表优化核心是避免磁盘i/o：优先内存临时表（engine=memory），严格匹配字段类型与索引，用批量insert+join替代超长in列表，必要时以exists或values子查询替代。
直接拼接超长 IN 列表（比如 5 万个 ID）几乎必然导致查询变慢、超时，甚至被 MySQL 拒绝执行。这不是语法错误，而是优化器在解析、计划、内存分配环节全面崩溃的信号。真正有效的解法不是“调大参数”，而是把“传一堆值”这件事从应用层搬到数据库内，用集合操作代替逐项比对。
CREATE TEMPORARY TABLE 必须带 ENGINE=Memory
临时表不是建出来就行，引擎选错等于白干。CREATE TEMPORARY TABLE temp_ids (id BIGINT UNSIGNED NOT NULL PRIMARY KEY) 默认可能走 InnoDB，而大批量 ID 的随机查找在磁盘上极慢。必须显式指定 ENGINE=Memory：
CREATE TEMPORARY TABLE temp_ids ( id BIGINT UNSIGNED NOT NULL PRIMARY KEY ) ENGINE=Memory;
-
Memory引擎把整张表放内存里，JOIN时能跑哈希联接，毫秒级响应 - 但注意：如果 ID 总量远超 10 万（比如 200 万），
Memory可能因max_heap_table_size限制报错，此时得切回InnoDB并加PRIMARY KEY或UNIQUE INDEX - 字段类型要和主表严格一致——主表
id是BIGINT，这里就不能用INT，否则隐式转换会让索引失效
BATCH INSERT 不是“一次插多条”，而是分批 executeBatch
很多人以为写 INSERT INTO temp_ids VALUES (1),(2),(3),...,(1000) 就算批量了，其实这只是单条 SQL 多值插入，仍受 max_allowed_packet 和解析开销拖累。真正高效的是 JDBC/ORM 层的批量提交：
- 用
PreparedStatement预编译INSERT INTO temp_ids (id) VALUES (?) - 每 1000 条调一次
pstmt.executeBatch()，而不是攒满 10 万再执行 - 别漏掉最后一组：循环结束后必须再调一次
executeBatch()，否则末尾数据丢失 - Python（PyMySQL）或 Node.js（mysql2）同理，找对应驱动的
batch或query批量接口，别用循环里反复execute
JOIN 时 ON 条件字段必须有索引，且大小写敏感要对齐
临时表建好了、数据插进去了，但 SELECT * FROM main_table t JOIN temp_ids tmp ON t.id = tmp.id 却没返回任何结果？大概率不是逻辑错，而是两个隐形陷阱：
- 主表
t.id字段没索引——JOIN会退化成嵌套循环，10 万 × 主表行数，直接卡死 - 临时表字段是
VARCHAR+_cs校对集（如utf8mb4_0900_as_cs），而你插入的 ID 字符串带大小写，但主表值全是小写，匹配全失败 - 更隐蔽的是字符集不一致：主表用
utf8mb4，临时表建表时没指定，MySQL 默认用latin1，比较时自动转码，索引失效
EXISTS 和 VALUES 子查询在什么场景下能替代临时表
临时表方案最稳，但不是唯一解。当 ID 来源本身就是另一张表查询结果时，优先考虑 EXISTS 或 VALUES 子查询，省去建表插数步骤：
- 用
EXISTS：适合主表大、子查询结果集小，且子查询能走索引的情况，例如WHERE EXISTS (SELECT 1 FROM users u WHERE u.status = 'active' AND u.id = t.user_id) - 用
VALUES表：MySQL 8.0.19+ 支持VALUES ROW(1), ROW(2), ...，可直接当内联表用，但超过几千行后性能断崖下跌，不如临时表可控 -
IN (SELECT ...)要警惕：如果子查询没走索引，或者优化器误判为相关子查询，性能可能比原始IN还差
临时表方案看似多几步，但它把不确定性全收束到可控环节：建表结构、插数批次、索引定义、JOIN 方式。所有变量都在 DBA 或开发手里，而不是交给优化器猜。最容易被忽略的其实是字段类型和校对集的一致性——差一个 UNSIGNED 或一个 _ci 后缀，就足以让整个优化归零。
