索引失效的根本原因是日期字段被函数包裹或隐式转换，而非子查询本身；如year(log_time)=2023导致索引失效，应改用log_time>='2023-01-01' and log_time
子查询里日期条件写错，索引照样失效——不是“用了子查询就一定慢”，而是日期字段一旦被函数包裹或隐式转换，外层再套几层子查询也没用。
WHERE 中对日期字段调用 YEAR()、DATE() 等函数
常见错误是把日期处理逻辑放在子查询的 WHERE 条件里，比如：
SELECT * FROM orders WHERE order_id IN ( SELECT order_id FROM logs WHERE YEAR(log_time) = 2023 );
哪怕 log_time 有索引，YEAR(log_time) 也会让索引失效，子查询退化为全表扫描，外层 IN 的性能直接崩掉。
- 改法：把函数挪到右边，用范围替代 ——
log_time >= '2023-01-01' AND log_time - 如果业务真要按年查且高频，考虑加生成列：
ALTER TABLE logs ADD COLUMN log_year INT AS (YEAR(log_time)) STORED，再给log_year加索引 - MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_log_year ON logs ((YEAR(log_time)))，但注意括号写法必须带双括号
子查询结果集过大导致优化器放弃索引
当子查询返回几千甚至上万行 ID，再用于外层 IN，MySQL 可能判定走索引不如全表扫描快，尤其配合 ORDER BY 或 LIMIT 时。
- 检查执行计划：
EXPLAIN看外层是否出现type=ALL或key=NULL - 优先用
JOIN替代IN子查询，特别是子查询结果稳定、可预估大小时 - 若必须用子查询，加
LIMIT控制结果规模（但需确认业务允许截断） - 避免在子查询里
SELECT *，只选必要字段，减少临时表开销
子查询中隐式类型转换破坏日期索引
典型场景是子查询里传入字符串格式的日期，而字段是 DATETIME 类型：
SELECT * FROM events WHERE event_date IN ( SELECT start_time FROM schedule WHERE status = 'active' AND start_time = '2023-05-01' );
如果 start_time 是 DATETIME，而 '2023-05-01' 没带时分秒，MySQL 可能触发隐式转换，导致索引不生效。
- 统一用完整时间格式：
'2023-05-01 00:00:00'或'2023-05-01 23:59:59'配合范围查询 - 更稳妥：子查询里显式转类型，如
CAST('2023-05-01' AS DATETIME)，但注意别作用在字段上 - 用
BETWEEN替代等值比较，避免精度丢失引发的隐式行为
真正卡住性能的往往不是子查询结构本身，而是日期字段在任意一层被加工过 —— 函数、截断、字符串拼接、时区转换，只要动了原始值，索引就大概率作废。盯住 EXPLAIN 里的 key 和 rows，比猜逻辑更可靠。
