存储过程中直接拼IN列表易崩，因MySQL解析器对字面量数量有隐式限制且优化器放弃索引；应改用CREATE TEMPORARY TABLE+INNER JOIN方案，注意类型一致、建主键、及时删除，并避免LEFT JOIN误用。
为什么存储过程中直接拼IN列表容易崩
MySQL 存储过程里用 CONCAT 拼出超长 IN 列表（比如 IN (1,2,3,...,5000)），执行时大概率会卡住或报错。根本原因不是语法错，而是 MySQL 解析器对单条语句中字面量参数数量有隐式限制（实际受 max_allowed_packet 和解析内存分配影响），且优化器面对几千个离散值时基本放弃走索引，转为全表扫描。
CREATE TEMPORARY TABLE + JOIN 是最稳的替代方案
把长列表塞进临时表再 JOIN，能绕过所有字面量解析瓶颈，还能让优化器按索引路径执行。关键点在于：临时表必须建在存储过程内、显式加索引、用完即删。
-
CREATE TEMPORARY TABLE temp_ids (id BIGINT UNSIGNED NOT NULL)—— 类型必须和目标列一致，避免隐式转换 -
INSERT INTO temp_ids VALUES (1),(2),(3),...,(5000)—— 批量插入比循环插入快 10 倍以上；若数据来自字符串参数，用SUBSTRING_INDEX+ 循环拆分，别用FIND_IN_SET -
ALTER TABLE temp_ids ADD PRIMARY KEY (id)—— 即使只查等值，主键也能强制走 hash lookup，比无索引快一个数量级 -
DROP TEMPORARY TABLE temp_ids—— 必须加，否则下次调用会报 “table exists”
注意 JOIN 写法细节，否则等于白改
写成 INNER JOIN 还是 LEFT JOIN 直接影响结果集。如果原逻辑是 WHERE id IN (...)，它天然过滤掉不匹配的行，对应必须用 INNER JOIN；若误写成 LEFT JOIN，会导致返回空值行，业务逻辑就错了。
- 正确写法：
SELECT t.* FROM your_table t INNER JOIN temp_ids ti ON t.id = ti.id - 别漏
STRAIGHT_JOIN（可选）：当优化器误判驱动表时，加这个能强制以temp_ids为小表驱动，减少扫描量 - 别在
JOIN条件里加函数，比如ON t.id = CAST(ti.id AS SIGNED)—— 会毁掉索引，临时表字段类型必须一步到位
临时表方案的边界在哪
临时表不是万能银弹。当传入 ID 数量低于 200 时，原生 IN 可能更快（省去建表、插入、删表开销）；超过 5 万时，INSERT ... VALUES 批量插入本身会变慢，此时该切到分区临时表或预置持久化映射表。真正需要警惕的是“动态拼 SQL + EXECUTE IMMEDIATE”这种老套路——它既难审计，又易被注入，还触发 QPS 陡增。
