mysql在where中写了索引字段却未走索引，常见原因是语句含分析函数（如row_number()），导致查询被重写为派生表或物化临时表，原始where条件无法下推，优化器被迫全表扫描。
MySQL 为什么在 WHERE 里写了索引字段却没走索引？
不是索引失效，也不是优化器抽风——常见原因是语句里混入了分析函数（如 ROW_NUMBER()、RANK()、LAG()），导致整个查询被重写为派生表（derived table）或物化临时表，原始 WHERE 条件无法下推到扫描层。
MySQL 8.0+ 支持窗口函数，但优化器对含分析函数的查询处理逻辑和普通查询完全不同：它必须先完成窗口计算（需要全量或分区排序），才能应用过滤。哪怕你只查 WHERE id = 123，只要语句里有 OVER (ORDER BY created_at)，优化器大概率会放弃用 id 索引做快速定位，转而走全表扫描 + 临时表 + 排序。
-
EXPLAIN中出现DERIVED或MATERIALIZED类型，且key为NULL，基本就是这个原因 - 即使
WHERE条件字段上有唯一索引，也不保证被使用 - 分析函数的
OVER子句若含非索引字段排序，会进一步加剧排序开销
如何判断是不是分析函数拖累了索引选择？
最直接的方法是拆解执行计划，对比“纯过滤”和“加窗口”的差异：
EXPLAIN SELECT * FROM orders WHERE order_id = 10001;
→ 查看 type 是否为 const 或 ref，key 是否命中索引
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
EXPLAIN SELECT *, ROW_NUMBER() OVER (ORDER BY created_at) rn FROM orders WHERE order_id = 10001;
→ 很可能变成 ALL + Using filesort + Using temporary
- 两个
EXPLAIN的rows值如果相差一两个数量级，基本可锁定问题来源 - 注意
filtered字段：加窗口后常降到 10% 以下，说明优化器预估过滤效果极差 - 用
SHOW STATUS LIKE 'Handler_%'对比两次查询的Handler_read_next，飙升说明实际做了全扫
绕过分析函数导致索引失效的实用方案
核心思路是「先过滤，再计算」，把窗口逻辑从主查询中剥离出来，避免优化器被迫物化整张表：
- 用子查询/CTE 显式限定数据集：
WITH filtered AS (SELECT * FROM orders WHERE order_id = 10001) SELECT *, ROW_NUMBER() OVER (ORDER BY created_at) rn FROM filtered;
→ 多数情况下能触发索引 - 如果业务允许，把窗口计算移到应用层：查出符合条件的几条记录后，在代码里排序编号，避免数据库排序压力
- 对高频点查场景，考虑冗余一个带序号的物化视图（MySQL 8.0.23+ 支持
CREATE MATERIALIZED VIEW），但需权衡维护成本 - 慎用
FORCE INDEX：对含窗口的语句基本无效，因为索引选择发生在物化前，而FORCE INDEX只影响扫描阶段
哪些分析函数组合会让问题更隐蔽？
单独一个 ROW_NUMBER() 就可能破坏索引，但以下组合会让优化器更难下推条件：
-
OVER (PARTITION BY category ORDER BY price)：分区键category若无索引，整个分区排序无法利用索引加速 -
LAG(col) OVER (ORDER BY id)+WHERE col IS NOT NULL：优化器可能误判col的空值分布，放弃id索引 - 多个窗口函数嵌套，如
ROW_NUMBER() OVER (...) + RANK() OVER (...)：触发多次排序，临时表膨胀更快 - 窗口函数与聚合混合，如
SUM(amount) OVER (...) + AVG(amount)：优化器倾向一次性物化全部中间结果
真正棘手的是那些看起来“只查一行”的语句，因为加了个 ROW_NUMBER() 就从毫秒级变秒级——这往往不是数据量问题，而是执行路径被分析函数悄悄改写了。
