IN子句嵌套查询在MariaDB中性能易崩，主因是dependent subquery导致N次执行、索引缺失或低区分度、大结果集物化落盘、IN列表超1000值引发解析开销与缓存失效；应改用JOIN、临时表或分批处理，并确保复合索引按最左前缀使用。
IN 子句嵌套查询在 MariaDB 中性能容易崩，尤其当子查询结果集大、或外层 WHERE 条件未走索引时，基本就是全表扫描起步。
explain 显示 dependent subquery 就说明有问题
执行 EXPLAIN SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active'); 时，如果 select_type 列出现 dependent subquery，代表子查询要为外层每一行重新执行一次——这不是“查一次再匹配”，而是“查 N 次”。常见诱因包括：
- 子查询里用了外层表字段（如
WHERE c.status = o.status），触发相关子查询 -
customers.id没有索引，或status列区分度低导致优化器放弃使用索引 - 子查询返回上万行，MariaDB 可能自动物化成临时表，但没走内存引擎，落到磁盘就慢
IN 列表超过 1000 个值时，别硬塞一个语句
MariaDB 对 IN (val1, val2, ...) 的硬编码列表有隐式限制：解析开销随元素数量非线性增长，5000 个值可能让 parse 阶段耗时翻倍。更麻烦的是，它会绕过查询缓存（即使内容相同），且容易触发 max_allowed_packet 截断。
- 实际测试中，
IN含 10000 个整数，耗时常比等价JOIN高 5–8 倍 - 若必须用大列表，拆成每次 500–1000 个值的批次，用
UNION ALL或应用层循环执行 - 避免把 Java
List<long></long>直接拼进 SQL——改用临时表：CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY); INSERT INTO tmp_ids VALUES (...); SELECT * FROM orders JOIN tmp_ids ON orders.customer_id = tmp_ids.id;
exists 比 in 更稳，但得看执行计划
表面看 EXISTS 和 IN 语义接近，但 MariaDB 优化器对 EXISTS 更倾向半连接（semi-join）优化，尤其在子查询不返回 NULL 时。不过不能无脑替换——得看 EXPLAIN 的 Extra 列：
- 出现
Using join buffer (Block Nested Loop)：说明没走索引，正在暴力嵌套循环 - 出现
Using where; Using index：理想状态，索引覆盖 + 条件下推 - 如果子查询带
ORDER BY或LIMIT，EXISTS可能提前终止，IN必须收齐全部结果
复合索引没按最左前缀用，嵌套就白搭
哪怕你给 customers(status, id) 建了索引，如果子查询写成 SELECT id FROM customers WHERE id IN (1,2,3) AND status = 'active'，MariaDB 仍可能忽略该索引——因为 id 在索引左侧，但 WHERE 条件没用到最左列 status。
- 正确写法是确保过滤条件从左到右连续使用索引列，例如
WHERE status = 'active' AND id > 1000 - 若业务常查 “某状态下的 ID 列表”，索引应为
(status, id)；若常查 “ID 对应的状态”，则建(id, status) -
SHOW INDEX FROM customers看Seq_in_index和Cardinality，确认索引是否被识别、区分度是否足够
真正卡住性能的，往往不是嵌套本身，而是嵌套暴露了索引缺失、参数配置不合理、或查询结构与数据分布不匹配。跑 EXPLAIN 是动作起点，但光看输出不够——得结合 SHOW PROFILE 或慢日志里的 Query_time 和 Rows_examined 才知道瓶颈到底在解析、IO 还是计算。
