MySQL 8.0 升级后，含数千个 IN(?, ?, ...) 参数的预处理语句执行变慢数十倍，根本原因是优化器在高基数参数场景下的计划生成与条件评估存在性能缺陷；该问题已在 MySQL 8.0.31 中官方修复。
mysql 8.0 升级后，含数千个 in(?, ?, ...) 参数的预处理语句执行变慢数十倍，根本原因是优化器在高基数参数场景下的计划生成与条件评估存在性能缺陷；该问题已在 mysql 8.0.31 中官方修复。
在将 MySQL 从 5.7 升级至 8.0 的过程中，许多开发者遇到了一个典型且隐蔽的性能退化现象：使用预处理语句（Prepared Statement）绑定大量参数（如 7000+ 个字符串）时，相同逻辑的查询执行时间从 MySQL 5.7 的约 100–250ms 暴增至 MySQL 8.0.28 的 10 秒以上，性能下降达 50 倍。值得注意的是，该问题仅出现在参数化查询中——若改用字符串拼接（即非安全但可复现对比的 IN('a','b',...)），性能则与 5.7 基本一致；同时 EXPLAIN 显示执行计划结构相似，但实际执行阶段（execute()）CPU 持续满载，95% 耗时集中于此，表明瓶颈不在网络或绑定环节，而在查询执行器内部。
深入分析可知，问题核心在于 MySQL 8.0.28 及更早版本中，优化器对动态生成的 IN 列表条件（尤其是超长参数列表）的谓词评估和索引选择逻辑存在低效实现。例如，在您的查询中：
SELECT c.product, a.name, b.value
FROM b
INNER JOIN a ON b.a_id = a.id AND a.name IN ('1be6f9eb563f3bf85c78b4219bf09de9')
INNER JOIN c ON c.b_id = b.id AND c.product IN (?, ?, ?, ..., ?); -- 7000+ 个参数
尽管 EXPLAIN 显示 c 表使用了 product 索引（type: ref, key: product），但 MySQL 8.0.28 在运行时需对每个参数逐一做类型检查、常量折叠与索引范围匹配，且该过程未有效缓存或向量化，导致时间复杂度近似线性增长。而 MySQL 5.7 的旧版优化器路径对此类场景做了更激进的启发式优化（如提前截断、批量哈希查找等），因而表现更优。
✅ 官方解决方案已落地：Oracle 在 MySQL 8.0.31 版本中正式修复了该性能回归问题（对应内部 Bug #106242 / #107195）。升级后，同等参数规模的预处理查询可恢复至与 5.7 相当的亚秒级响应（实测 7000 参数下稳定在 150–300ms），CPU 占用恢复正常，EXPLAIN ANALYZE 也显示各阶段耗时分布合理。
? 临时缓解建议（如暂无法升级）：
- 避免单条语句传递超 1000 个
IN参数；改用分批查询（如每批 500 项 +UNION ALL）； - 对高频大列表场景，考虑将参数写入临时表（
CREATE TEMPORARY TABLE tmp_params (...)），再通过JOIN替代IN； - 确保
c.product字段使用utf8mb4_bin或utf8mb4_0900_as_cs等高效排序规则，避免隐式转换放大开销； - 关闭
optimizer_switch='condition_fanout_filter=off'（实验性，需充分测试）。
⚠️ 重要提醒：切勿为规避此问题而长期采用字符串拼接构造 SQL —— 这将引入严重 SQL 注入风险，违背安全开发基本原则。预处理语句的安全价值远高于短期性能妥协。
综上，该问题本质是 MySQL 8.0 早期版本优化器演进中的阶段性性能缺陷，而非应用层代码错误。强烈建议生产环境直接升级至 MySQL 8.0.31 或更高版本（如 8.0.33+），并配合 mysql_upgrade 工具更新系统表，即可一劳永逸解决该类大规模参数绑定性能退化问题。
