1.5.2 B+Tree（多路平衡树）索引与优化器

本册承接 1.5.1 的页与缓存模型，只回答“查询怎样定位记录、为何选择这条访问路径、如何用证据纠正慢查询”三个问题。事务可见性、锁范围、日志和分片分别由后续分册展开。

1. 学习目标、边界与版本口径

你应能把一条订单、库存 SKU（库存单位）或轨迹分页 SQL（结构化查询语言）解释成“索引键比较 → 叶页扫描 → 是否回表 → 过滤/排序/连接 → 返回行”的成本链；也能区分估算与实测，避免把 EXPLAIN（执行计划）当成真实性能结论。

版本	本册可直接使用的结论	不能混写的边界
MySQL（关系型数据库）5.7	B+Tree（多路平衡树）、索引条件下推、Multi-Range Read（多范围读取）、Batched Key Access（批量键访问）和传统统计信息	没有 `EXPLAIN ANALYZE`（实际执行分析）、直方图、降序索引、不可见索引；Hash Join（哈希连接）不能倒写
MySQL（关系型数据库）8.0	直方图、降序索引、不可见索引、`EXPLAIN ANALYZE`（实际执行分析）和 Hash Join（哈希连接）按具体小版本可用	`EXPLAIN ANALYZE`（实际执行分析）从 8.0.18 起可用；Hash Join（哈希连接）从 8.0.18 起引入，不能泛化成全部 8.0
MySQL（关系型数据库）8.4	长期支持版本中的同类能力与较新的优化器实现	迁移时仍需以实际小版本、`optimizer_switch`（优化器开关）和执行计划验证，不能只凭大版本

flowchart LR
    A["SQL（结构化查询语言）谓词"] --> B["候选索引与统计信息"]
    B --> C["优化器成本比较"]
    C --> D["索引访问 / 全表扫描"]
    D --> E["回表、过滤、排序、连接"]
    E --> F["实际行数与耗时"]
    F -.与估算不符.-> B

图中不是“有索引必走索引”：统计信息决定估算行数，成本模型再比较顺序读、随机读、排序和连接代价。发生偏差时要把实际行数回灌到排查，而不是先强制索引。

2. B+Tree（多路平衡树）的页、层高与结构维护

2.1 页扇出、层高与叶页链表

B+Tree（多路平衡树）把大量键拆到有序页中：非叶页保存分隔键和子页指针，叶页保存聚簇记录或“二级键 + 主键”，叶页用双向链表相连。查等值时每层只选一个子页；查范围时先定位左边界，再顺着叶页走。目录槽用于页内二分定位，不能把它误说成整棵树的目录。

结构	保存内容	查询作用	写入代价
根页	少量分隔键与子页指针	确定第一条分支	极少变更但分裂会向上影响
非叶页	分隔键与子页指针	逐层缩小页范围	父页满时可能递归分裂
叶页	记录或二级键 + 主键	返回等值结果和承接范围扫描	中间插入易造成页分裂
叶页链表	前后页指针	避免范围查询反复回根	页合并时需维护邻接关系

flowchart TD
    R["根页：≤500 / ≤1000"] --> N1["非叶页：≤100 / ≤300"]
    R --> N2["非叶页：≤700 / ≤900"]
    L1["叶页 P11：1..100"] --> L2["叶页 P12：101..300"]
    L2 --> L3["叶页 P13：301..500"]
    L3 --> L4["叶页 P14：501..700"]
    L4 --> L5["叶页 P15：701..1000"]
    N1 --> L1
    N1 --> L2
    N1 --> L3
    N2 --> L4
    N2 --> L5

数据演绎 1：用页扇出估算层高。 假设 16 KiB（千字节）页可用 15,000 字节，非叶条目为 8 字节键 + 6 字节子页号 + 4 字节记录开销，扇出约 15000 / 18 = 833；叶页平均一条二级记录 40 字节，约放 375 条。三层容量约为 833 × 833 × 375 = 260,208,375 条。即使保守按半页与额外开销折减到 30%，也能容纳约 7800 万条，因此常见千万级表等值定位通常只需根、非叶、叶三次页访问；前提是缓存未命中才发生磁盘 I/O（输入输出）。

2.2 聚簇索引、二级索引、回表与覆盖

InnoDB（事务存储引擎）聚簇索引叶页保存整行记录；二级索引叶页保存二级键和主键值。二级索引命中但查询列不在叶页时，数据库要拿主键再走一次聚簇索引，这一步称回表。若筛选、排序和返回列都可由同一索引叶页提供，便是覆盖索引，Extra（额外信息）常显示 Using index（使用覆盖索引），但这不等同于所有过滤都无代价。

访问形态	叶页可得内容	是否访问聚簇页	主要风险
主键等值	完整行	否，已在聚簇叶页	返回列过宽与热点页竞争
二级索引回表	二级键、主键	是	主键分散时随机页访问多
覆盖索引	条件、排序、返回列均在二级叶页	否	索引过宽带来写放大
索引条件下推	可先判断的索引列	仅合格行回表	不能消除宽范围索引扫描

sequenceDiagram
    participant Q as 查询
    participant S as 二级索引叶页
    participant P as 聚簇索引叶页
    Q->>S: user_id=42 and status='PAID'
    S-->>Q: order_id=9001
    Q->>P: 按主键取 amount、created_at
    P-->>Q: 完整记录
    Note over Q,S: 若二级叶页包含所需列，则省略回表

数据演绎 2：回表成本不是“多一次”这么简单。 t_order 有 2000 万行，查询某用户 5000 个已支付订单；二级索引连续扫描 5000 条约读取 14 个叶页，但每条都回表且主键分散，最坏可能触达数千个聚簇页。若业务只展示 order_id、created_at、amount，索引 (user_id,status,created_at,amount) 可覆盖返回字段；代价是每次写订单都要维护更宽的二级叶页。应以读写比例、索引体积和真实热点决定，不能给所有列堆“万能覆盖索引”。

2.3 联合索引、最左前缀与范围截断

联合索引按字典序排列，例如 (warehouse_id, sku_code, available_qty) 先按仓库，再按 SKU（库存单位），最后按可用量。等值条件能持续缩小前缀；第一个范围条件之后，后续列通常不能继续用于定位连续索引区间，但仍可能参与索引条件下推或覆盖。LIKE 'AB%'（前缀匹配）可形成范围，LIKE '%AB'（后缀匹配）通常不能；对列做函数、隐式类型转换或不满足排序方向，也会改变可用索引能力。

条件形状	对 `(warehouse_id,sku_code,available_qty)` 的定位能力	设计含义
仓库等值 + SKU（库存单位）等值	使用两个前缀精确定位	适合单条库存读取
仓库等值 + SKU（库存单位）范围	前缀后形成连续范围	可顺序扫描仓内编码区间
缺仓库只查 SKU（库存单位）	不能按左前缀精确定位	需要另一索引或接受扫描
仓库等值 + SKU（库存单位）范围 + 可用量条件	前两列定位，第三列可过滤	不能宣传第三列继续缩小范围

flowchart LR
    A["(warehouse_id, sku_code, available_qty)"] --> B["warehouse_id = 8"]
    B --> C["sku_code >= 'A' 且 < 'B'"]
    C --> D["available_qty > 0"]
    D --> E["前两列定位区间；第三列可过滤但通常不再缩小定位前缀"]

数据演绎 3：字段顺序由选择性和查询形状共同决定。 1000 万库存记录中有 50 个仓、80 万 SKU（库存单位）。warehouse_id=8 平均剩 20 万行，sku_code='S100' 平均只剩 1 行；查单个库存时 (warehouse_id,sku_code) 和 (sku_code,warehouse_id) 都可等值定位，但若常做“某仓下所有 SKU（库存单位）按编码翻页”，前者能保持仓内连续顺序。若谓词为 warehouse_id=8 AND sku_code LIKE 'S1%' AND available_qty>0，第三列不应被宣传为继续缩小 B+Tree（多路平衡树）定位范围；它可由索引条件下推减少回表。

2.4 排序、分组、降序与深分页

索引能避免排序的前提是：过滤后的结果仍按索引顺序输出，排序列顺序、方向和前导等值条件都与索引兼容。MySQL（关系型数据库）8.0 支持真正的降序索引；5.7 的索引方向不提供同等能力，不能把 8.0 的混合方向排序经验直接迁移。LIMIT offset,size（偏移分页）即使只返回 20 行，也可能扫描并丢弃 offset + size 行；关键集分页用最后一条排序键继续查，更接近“只读取下一页”。

需求	索引/查询条件	结果	边界
租户内倒序列表	租户等值 + 时间、主键同向排序	可顺序读取	排序方向和列序必须匹配
混合方向排序	MySQL（关系型数据库）8.0 降序索引	可按定义方向读取	5.7 不应按此假设设计
偏移分页	`LIMIT offset,size`（偏移分页）	仍丢弃前置记录	页深会线性放大扫描
游标分页	最后时间 + 主键作严格边界	从叶页当前位置继续读	不适合任意跳页

flowchart TD
    A["订单：tenant_id=9，按 created_at、id 倒序"] --> B{"索引 (tenant_id, created_at DESC, id DESC)?"}
    B -->|是| C["顺序扫描 20 条"]
    B -->|否| D["取候选行 → filesort（文件排序）→ LIMIT（限制返回行数）"]
    E["下一页游标：(last_created_at,last_id)"] --> C

数据演绎 4：深分页的丢弃成本。 某租户每天 200 万订单，列表第 50,001 页每页 20 行，偏移方案需要从有序结果中读取至少 50,000 × 20 + 20 = 1,000,020 条，再丢弃前 100 万条；若每条还回表，成本更高。游标方案使用 WHERE tenant_id=9 AND (created_at,id) < ('2026-07-14 10:00:00',9001) ORDER BY created_at DESC,id DESC LIMIT 20，索引从上页末尾继续读取约 20 条。游标不是随机跳页方案，产品若必须跳页，应限制最大页数、按时间分段或提供异步导出。

3. 优化器：统计信息、成本与执行证据

3.1 统计信息、基数与直方图

优化器需要估算每个条件剩多少行。基数描述不同值数量，选择性常可近似为 满足条件行数 / 总行数；索引统计通常由采样页推断，数据倾斜或列相关性会使独立性假设失真。MySQL（关系型数据库）8.0 的直方图可补充无索引列或偏斜列的分布认识，但它不是自动创建，也不是多列联合分布的万能替代。

统计现象	可能导致的计划偏差	应先验证什么
批量导入或归档	旧采样不再代表当前行数	统计更新时间与数据变更量
头部租户/承运商	平均选择性严重失真	分桶后的真实条件命中数
列高度相关	单列选择性乘法低估或高估	组合维度的实际分布
无索引过滤列偏斜	候选访问路径比较错误	直方图适用性与版本边界

flowchart LR
    A["表行数 1000 万"] --> B["采样索引页"]
    B --> C["基数 / 选择性估算"]
    D["直方图：值分布"] --> C
    C --> E["估算 rows（扫描行数）"]
    E --> F["成本与访问路径"]
    G["数据倾斜、相关列、陈旧统计"] -.偏差.-> E

数据演绎 5：低基数不等于不能用索引。 1000 万订单中 status='PAID' 占 90%，单查支付状态估算要读 900 万行，索引通常不划算；但加入 tenant_id=9 后该租户仅 2 万行，其中支付单 1.8 万行，仍不够选择性；再加 created_at >= 今天 剩 300 行，联合索引 (tenant_id,created_at,status) 可高效定位。字段基数必须放进完整谓词、数据分布和返回列讨论，不能只看“状态列只有几个值”。

3.2 成本模型、访问类型与 `EXPLAIN`（执行计划）

成本模型会比较全表扫描、索引范围扫描、回表随机读、排序和连接等代价。EXPLAIN（执行计划）的 type（访问类型）是访问方式标签，通常 const（常量访问）、eq_ref（唯一等值连接）、ref（非唯一等值访问）、range（范围访问）、index（全索引扫描）、ALL（全表扫描）从“通常更精确”到“通常更宽泛”，但不是性能排名表。rows（预估扫描行数）是估算，filtered（过滤百分比）表示本表条件后预计留下的百分比；二者相乘可粗略得到传给下一步骤的行数。

字段	应怎样读	常见误判
`key`（实际索引）	实际选择的索引	有 `key`（实际索引）不代表扫描行少
`key_len`（使用键长）	参与访问的键前缀长度	不能单独推断所有条件都被索引定位
`rows`（预估扫描行数）	统计模型的估算扫描量	不是实际返回行数
`filtered`（过滤百分比）	本表剩余比例估算	需要与 `rows`（预估扫描行数）一起看
`Extra`（额外信息）	过滤、覆盖、临时表、排序等附加动作	不是一行一个绝对好坏结论

flowchart TD
    A["候选访问路径"] --> B["估算 rows（扫描行数）"]
    B --> C["估算回表 / 排序 / 连接成本"]
    C --> D["选最低估算成本"]
    D --> E["EXPLAIN（执行计划）"]
    E --> F["EXPLAIN ANALYZE（实际执行分析）"]
    F --> G["比较估算行与实际行"]

数据演绎 6：把 rows（预估扫描行数）和 filtered（过滤百分比）翻译成风险。 某轨迹查询计划显示 rows=200000、filtered=2.5，则优化器预期约 5000 行进入下一节点；若下一节点是按主键回表并排序，这已是高风险。EXPLAIN ANALYZE（实际执行分析）若显示实际扫描 180 万、输出 4.8 万，说明不是“慢一点”，而是统计或条件相关性存在数量级误差。此时先核对日期范围、参数类型、索引前缀与统计，再改查询或索引。

3.3 `EXPLAIN ANALYZE`（实际执行分析）、`Extra`（额外信息）与索引下推

EXPLAIN（执行计划）展示优化器估算与选择，EXPLAIN ANALYZE（实际执行分析）实际执行语句并报告时间、循环与真实行数，线上使用前要确认它会真正运行查询，避免对写语句或重负载语句造成影响。Extra（额外信息）中的 Using index condition（使用索引条件下推）表示 Index Condition Pushdown（索引条件下推）把部分二级索引列条件放在存储引擎层筛掉，从而减少回表；它不等于覆盖索引，也不能突破第一个范围后的索引定位边界。

`Extra`（额外信息）信号	表示什么	不应推导什么
`Using index`（使用覆盖索引）	所需列可从索引取得	选择性一定很高
`Using index condition`（使用索引条件下推）	索引层先过滤部分条件	完全不扫描范围内索引条目
`Using temporary`（使用临时表）	有中间结果物化	必然落磁盘或必然要消除
`Using filesort`（使用文件排序）	不能直接沿索引输出排序	一定写文件

flowchart LR
    A["二级索引扫描"] --> B{"索引列条件"}
    B -->|ICP（索引条件下推）过滤| C["少量主键"]
    C --> D["回表取非索引列"]
    B -->|无 ICP（索引条件下推）| E["更多主键回表后过滤"]

数据演绎 7：ICP（索引条件下推）减少的是回表，不是索引扫描。 索引 (tenant_id, created_at, status) 查询 tenant_id=9 AND created_at BETWEEN ... AND status='DELIVERED'：前两列构成范围，扫描到 10 万个二级条目，状态条件不能再把范围变成一个更窄的连续区间；开启 ICP（索引条件下推）后引擎先在叶页过滤，只把 3000 个主键回表。它仍扫描约 10 万个索引条目，因此若范围本身太宽，重点仍是时间窗口和索引顺序。

4. 连接、排序与优化器的执行选择

4.1 MRR（多范围读取）、BKA（批量键访问）与连接顺序

Nested Loop Join（嵌套循环连接）以外表每一行去内表查一次。Multi-Range Read（多范围读取）可收集二级索引得到的主键并按主键顺序读取，降低随机回表；Batched Key Access（批量键访问）把外表连接键成批交给内表，借助 MRR（多范围读取）改善内表访问局部性。它们是否启用受版本、连接类型、成本和 optimizer_switch（优化器开关）影响，不能把开关打开就当作性能保证。

技术	缓解的成本	前提	不能解决的根因
Nested Loop Join（嵌套循环连接）	用内表索引降低单次探测	外表已充分过滤	外表意外放大
MRR（多范围读取）	二级索引回表的随机页访问	可批量收集主键范围	缺少正确索引前缀
BKA（批量键访问）	连接内表的重复随机探测	合适连接与优化器选择	错误驱动顺序
Hash Join（哈希连接）	某些等值连接的重复探测	8.0.18+ 且成本合适	范围、排序和构建侧过大

sequenceDiagram
    participant O as 订单外表
    participant B as BKA（批量键访问）缓冲
    participant I as 库存内表索引
    O->>B: 收集一批 sku_id
    B->>I: 批量探测
    I->>I: MRR（多范围读取）按主键顺序取页
    I-->>O: 返回匹配库存

数据演绎 8：连接顺序的倍数效应。 订单表 1000 万行，日期条件预计筛到 2 万行；库存表 200 万行，仓库条件筛到 5 万行。若先驱动库存再连接订单，且每个库存记录平均匹配 40 条历史订单，内层探测可能放大到 200 万次；若先按日期筛订单 2 万，再用 (warehouse_id,sku_id) 查库存，通常只做 2 万次精确探测。真正顺序还要看选择性和索引，不能固定“表小先驱动”。

4.2 临时表、filesort（文件排序）与 Hash Join（哈希连接）

Using temporary（使用临时表）表示需要物化中间结果，可能在内存也可能落盘；Using filesort（使用文件排序）表示额外排序算法，也不保证写文件。二者是提示而非定罪。Hash Join（哈希连接）在 MySQL（关系型数据库）8.0.18 起用于合适的等值连接场景：构建较小输入的哈希表，再扫描另一输入探测；它不替代索引，也不适用于所有连接谓词。

flowchart TD
    A["连接 / 分组 / 排序"] --> B{"索引顺序可直接满足?"}
    B -->|是| C["流式返回或流式聚合"]
    B -->|否| D["中间结果"]
    D --> E["临时表 / filesort（文件排序）"]
    F["等值连接且成本合适"] --> G["Hash Join（哈希连接）"]

数据演绎 9：临时表与排序谁更值得修。 “按承运商统计近 30 天异常轨迹并取前 20 名”先过滤 300 万行，再按承运商聚合为 80 个组，出现临时表但只存 80 行，通常不是首要矛盾；若先连接订单产生 5000 万行再排序，filesort（文件排序）处理巨量宽行才是主问题。先缩小日期、租户和异常状态驱动集，再决定预聚合、覆盖索引或汇总表，而不是看到任一 Extra（额外信息）就机械加索引。

4.3 优化器误判、Hint（提示）与不可见索引边界

优化器误判常来自陈旧统计、抽样遗漏、列相关性、参数分布差异、隐式转换、成本常量与缓存冷热差异。先保留 SQL（结构化查询语言）、绑定参数、表定义、索引、统计时间、计划和实际执行证据，复现后再修改。Optimizer Hint（优化器提示）如 USE INDEX（建议索引）、FORCE INDEX（强制索引）、连接顺序提示只约束一个特定计划选择；它们会把当前分布假设固化，适合短期止血或经压测的稳定特殊查询，不是长期替代统计和索引设计。

flowchart TD
    A["慢查询"] --> B["保全参数、计划、实际行数"]
    B --> C{"估算与实际差异大?"}
    C -->|是| D["统计、倾斜、相关性、类型"]
    C -->|否| E["回表、排序、连接、锁/资源"]
    D --> F["更新统计 / 重写 / 改索引"]
    E --> F
    F --> G["同量级验证"]
    G --> H["Hint（提示）仅作受控兜底"]

数据演绎 10：错误 Hint（提示）如何从止血变成事故。 大促当天 status='PENDING' 占比从 1% 升到 55%，历史计划用状态索引很快；开发用 FORCE INDEX（强制索引）固化后，优化器无法改选更便宜的顺序扫描，数百万随机回表拖慢订单接口。正确流程是记录占比变化和实际计划，评估 (tenant_id,created_at,status) 是否贴合查询；若必须临时提示，设定到期时间、指标阈值和撤销条件，并在流量回落后复验。

4.4 线上证据模型与项目话术

索引优化的目标不是“计划漂亮”，而是让正确业务语义以可预测资源完成。线上证据至少包含请求量、参数分布、扫描行数、返回行数、排序/临时表、回表、连接循环、缓存和等待；项目话术要说明错误方案为何失败，以及如何验证没有把读优化转成写事故。

flowchart LR
    A["订单列表 P95（第 95 百分位）升高"] --> B["参数分桶"]
    B --> C["计划 / 实际行数"]
    C --> D["索引、统计、排序、连接"]
    D --> E["限流 / 游标 / 索引或查询修复"]
    E --> F["同量级压测与上线观测"]

场景	常见错误	可复述的正确边界
订单查询	给每个筛选字段单列索引	按等值过滤、范围、排序和返回列设计联合索引，再用真实参数验证
库存 SKU（库存单位）	用宽随机主键并让每次扣减先全表找	用业务唯一约束和精确索引定位；扣减原子性由后续锁/条件更新章节保证
轨迹分页	`LIMIT offset,size`（偏移分页）无限翻页	使用时间 + 主键游标、稳定排序和最大查询窗口
支付对账	列表 `SELECT *`（查询全部列）并深分页	列表覆盖索引、详情按主键取、导出异步分批

4.5 综合题库过渡（非知识型）

本节只说明题库使用方式，用于结束上一知识条目，因此不添加 kb:knowledge（知识条目）标记。

5. 综合面试题与追问

本节是非知识型过渡，不添加 kb:knowledge 标记。每题的口述答案控制在三至五分钟，并把机制、证据、失败边界和项目决策串成一条线。章节细节回链均指向本册，避免跨册复制事务与锁正文。

问题：请从页、层高和范围扫描解释 InnoDB（事务存储引擎）为什么使用 B+Tree（多路平衡树）。
- 口述答案：我会先把数据库的读取单位说清：存储引擎不是为一个键做一次磁盘访问，而是把 16 KiB（千字节）页读入缓存。B+Tree（多路平衡树）的非叶页只放分隔键和子页指针，所以一个页可以指向数百个下级页；百万到千万级记录通常三到四层即可定位。等值查询从根页逐层比较，到叶页得到记录或主键。范围查询先定位下界，再沿叶页双向链表顺序取，不必反复回根。页内还有目录槽，帮助在当前页二分找记录。写入不是免费：中间键插入到满页会触发分裂、父页增加分隔键，删除后可能合并或重组织，因此随机宽主键更容易造成碎片和写放大。面试中我不会说“三层一定三次磁盘 I/O（输入输出）”，因为根和热点非叶页通常在 Buffer Pool（缓冲池）中，真正延迟还取决于叶页命中、回表和返回量。库存表若按随机 UUID（通用唯一标识）聚簇，会让写入分散且二级索引都携带宽主键；我会优先评估紧凑趋势递增内部标识，再用仓库 + SKU（库存单位）唯一约束表达业务不变量。最后用页分裂率、索引大小、缓存命中和写延迟验证，而非只背树高。
- 详细章节与验证：本册 2.1：页扇出、层高与叶页链表。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：顺序键是否绝对最好？答：它改善局部性，但右侧热点、分片路由和标识生成成本仍需压测。
- 追问：哈希索引为何不替代它？答：哈希适合等值，不能自然支持范围、排序和前缀扫描。
- 追问：树高增加一层意味着什么？答：多一次页访问机会，但缓存命中和后续回表往往更关键。
问题：聚簇索引、二级索引、回表和覆盖索引怎样用一条订单查询讲清？
- 口述答案：以订单表为例，聚簇索引叶页保存完整订单行；二级索引叶页保存二级键和主键值，而不是直接保存行地址。查询 user_id（用户标识）和状态时，先走二级索引拿到主键；若还要金额、地址等不在二级叶页的列，就按主键再访问聚簇索引，这叫回表。它的风险不是概念上的“多一步”，而是命中几千条时主键可能分散在大量聚簇页，随机访问和缓存竞争会放大。订单列表只展示订单号、创建时间、金额、状态时，我会先固定投影，再评估 (user_id,status,created_at,amount) 是否可覆盖；详情页再按主键回表。覆盖索引能减少回表，却会增加索引页宽度、写入维护和磁盘占用，所以不能把所有列塞进去。判断是否值得，要看读写比例、列表频率、返回行数和写入指标。Using index（使用覆盖索引）只说明列可从索引取得，不保证条件选择性好，也不保证没有排序。支付对账会把在线列表与全量导出分开：前者覆盖读取并限制页大小，后者异步、游标分批、固定查询上界，避免一次查询既宽又深。
- 详细章节与验证：本册 2.2：聚簇索引、二级索引、回表与覆盖。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：为什么二级索引保存主键？答：页移动后不需更新所有二级地址，代价是主键宽度会扩散到每个二级索引。
- 追问：覆盖索引何时反作用？答：低频列、大字段或高频更新列会降低扇出并放大写成本。
- 追问：如何证明减少回表？答：对比实际扫描、读取页、节点耗时和写侧延迟，而非只看 Extra（额外信息）。
问题：联合索引的字段顺序怎样设计，最左前缀和范围截断怎样解释？
- 口述答案：联合索引不是多个单列索引的拼接，而是按定义顺序形成字典序。例如 (warehouse_id,sku_code,available_qty) 先按仓库，再按 SKU（库存单位），最后按可用量排列。等值条件会持续固定左侧前缀；出现第一个范围条件后，后列通常不能继续把 B+Tree（多路平衡树）定位区间缩小成连续更小范围，但可能做索引条件下推或覆盖。因此字段顺序不能只按“基数高在前”背口诀，要先列高频查询：查单条库存需要仓库和 SKU（库存单位）等值；仓内浏览需要仓库等值、SKU（库存单位）排序；缺货巡检还带可用量范围。不同查询可能需要不同索引，不能期待一个索引服务所有形状。对于 LIKE 'AB%'（前缀匹配），可以转成连续范围；LIKE '%AB'（后缀匹配）则不具备左侧锚点。对日期列做函数、把字符串列与数值参数比较，也会破坏可搜索性或改变比较语义，应改写成原列范围并统一参数类型。设计完成后，用真实参数看扫描行数、排序和回表，尤其关注范围过宽时后列过滤看似生效但仍扫描大量二级条目的情况。
- 详细章节与验证：本册 2.3：联合索引、最左前缀与范围截断。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：IN（集合匹配）算范围吗？答：可拆多个等值范围，后列利用程度由数量、成本和版本决定。
- 追问：缺第一列还能用吗？答：可能索引扫描或特例优化，但不是稳定的高选择性访问设计。
- 追问：怎么选前缀索引长度？答：比较不同长度的不同值比例、索引大小和实际误命中回表。
问题：怎样用联合索引优化订单列表排序，同时避免深分页？
- 口述答案：我先定义列表的稳定语义：同一租户内按创建时间倒序，同一时间再按订单主键倒序，列表只返回必要字段。然后让索引顺序匹配 (tenant_id,created_at DESC,id DESC)，并把常用展示字段按成本评估是否覆盖。前导租户等值固定后，叶页内的时间和主键顺序可直接输出，避免额外排序；若排序方向、列次序或过滤条件破坏这个顺序，仍可能出现 filesort（文件排序）。深分页不能仅靠索引治愈，因为偏移方案仍须读取并丢弃前面记录。第 5 万页每页 20 条，数据库至少经过 100 万条候选；如果还有回表，代价会指数般放大。正确方式是关键集分页：客户端保存上页最后的 (created_at,id)，下一页严格小于该元组，索引从当前位置顺序读取 20 条。新增数据或相同时间不会重复，是因为主键提供全序。它不支持任意跳页，所以产品需要给时间筛选、最大翻页阈值或异步导出，而不是把随机跳页伪装成普通在线接口。上线前我会验证长尾租户、最深游标、写入期间翻页和索引写放大。
- 详细章节与验证：本册 2.4：排序、分组、降序与深分页。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：5.7 能完全等价处理混合方向吗？答：不能把 8.0 降序索引能力倒写到 5.7，应按版本与实际计划验证。
- 追问：游标能随机跳页吗？答：不擅长，应提供时间定位、分段统计或导出能力。
- 追问：时间相同怎么办？答：时间与唯一主键共同排序、共同作为游标边界。
问题：为什么低基数状态列也可能出现在有效联合索引中？
- 口述答案：低基数只说明该列的不同取值少，不等于它在完整查询里没有价值。比如 1000 万订单中支付状态占 90%，单独用状态索引可能要读取 900 万条，顺序扫描反而更便宜；但在 tenant_id=9、最近一天、状态为支付成功的组合下，租户与时间先把候选集压到几百条，状态列再参与过滤、覆盖或排序就可能合理。索引顺序应由等值前缀、范围、排序、返回列和读写成本共同决定。还要警惕数据倾斜：某租户的状态分布可能和全表完全不同，优化器基于全局采样容易误算。我的排查方式是先按真实参数统计总行数、各条件逐层剩余量和头部租户分布，再看 EXPLAIN（执行计划）的估算是否接近；若差异很大，再评估统计刷新、直方图、查询改写或索引。不能因为听说“低基数不建索引”就放弃组合设计，也不能把每个枚举列都追加到索引尾部。对高频写订单表，还要计算该列变化时二级索引维护和页膨胀的代价。
- 详细章节与验证：本册 3.1：统计信息、基数与直方图。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：唯一索引一定最优吗？答：等值查通常极好，但范围、排序和连接可能由其他联合索引总体胜出。
- 追问：基数如何获得？答：索引统计可估算，业务排查还应按真实维度聚合验证。
- 追问：状态变更频繁怎么办？答：评估写放大、索引维护和是否应该走独立检索或汇总模型。
问题：统计信息、直方图和列相关性如何导致优化器选错索引？
- 口述答案：优化器无法逐条执行所有候选方案，只能用表行数、索引基数和分布统计估算每一步剩余行数，再比较回表、排序和连接成本。误判首先来自统计陈旧：批量导入、归档或状态迁移后，采样页不再代表当前分布。第二类是倾斜，例如少数承运商占绝大多数轨迹，平均分布假设会失真。第三类是列相关性：国家、渠道、状态在真实业务中相关，但模型常把单列选择性相乘，得到数量级错误。MySQL（关系型数据库）8.0 的直方图能补充某列值分布，适合无索引过滤列或明显偏斜列，但不是多列联合分布的万能答案。治理顺序是保留慢 SQL（结构化查询语言）与参数，比较估算和实际行数，确认统计更新时间和数据变化，再低峰或副本验证 ANALYZE TABLE（分析表）与直方图影响；如果查询形状本身缺少租户、时间等强约束，应先修查询和索引。绝不能只刷新统计就宣布解决，也不应为了一个异常参数永久强制索引。
- 详细章节与验证：本册 3.1：统计信息、基数与直方图。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：直方图加速读吗？答：它改善行数估算和计划选择，不提供新的物理访问路径。
- 追问：何时刷新统计？答：大批量数据形态变化后，先评估负载并在受控环境验证。
- 追问：如何发现相关性？答：比较单列乘积估算与按组合维度真实聚合的结果。
问题：如何系统阅读一份 EXPLAIN（执行计划）？
- 口述答案：我不从 type（访问类型）排行榜开始，而是按数据流读。先核对 SQL（结构化查询语言）参数和表别名，确认每个表是被谁驱动；再看 key（实际索引）和 key_len（使用键长）是否符合预期前缀；接着读 rows（预估扫描行数）与 filtered（过滤百分比），相乘估算会传给下一节点多少行。然后看 Extra（额外信息）：覆盖、索引条件下推、临时表和排序分别说明过滤位置与附加工作。const（常量访问）、eq_ref（唯一等值连接）、ref（非唯一等值访问）、range（范围访问）、index（全索引扫描）、ALL（全表扫描）只是访问形态；小维表全表扫描可能正常，千万订单表高并发全扫才危险。最后把每层估算串成乘法链，找出最早开始放大的节点。若计划看似合理仍慢，就用 EXPLAIN ANALYZE（实际执行分析）在安全环境验证真实扫描、循环和节点耗时。这样能区分统计误判、回表过多、排序、连接顺序和资源等待，避免见到 ALL（全表扫描）就乱建索引。
- 详细章节与验证：本册 3.2：成本模型、访问类型与执行计划。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：rows（预估扫描行数）是返回行吗？答：不是，它是访问方法预期扫描量。
- 追问：filtered（过滤百分比）为何重要？答：它决定下游连接或排序会收到多少行。
- 追问：possible_keys（可能索引）为空就是无优化空间吗？答：不一定，可能是查询形状、表达式或全扫成本更合理。
问题：EXPLAIN ANALYZE（实际执行分析）怎样用于定位统计误判，线上有什么限制？
- 口述答案：EXPLAIN（执行计划）是优化器的预测，EXPLAIN ANALYZE（实际执行分析）会真正运行查询并给出每个节点实际行数、循环次数和耗时。定位时我先选择代表性参数，记录计划中的 rows（预估扫描行数），再对照实际扫描。若上游本应输出 100 行却输出 10 万行，后续索引回表、嵌套循环和排序即使单次很快也会被放大；根因通常在上游选择性、统计或类型转换。若估算接近但耗时高，则继续查缓存冷热、磁盘、网络、锁等待和返回体积。它的限制是会执行 SQL（结构化查询语言），所以不能在生产尖峰直接对写语句、超大结果集或可能持锁的查询试验；应优先只读副本、回放库、限流会话或低峰短窗口，并对参数和耗时设上限。一次结果也不是绝对真相，缓存状态和并发会波动，至少要同条件重复并记录环境。最终修复要以同量级压测验证实际行数下降、p95（第 95 百分位）改善和写侧没有显著退化。
- 详细章节与验证：本册 3.3：实际执行分析、额外信息与索引下推。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：为什么不能只看总耗时？答：总耗时不告诉你行数从哪里放大、哪一节点反复循环。
- 追问：是否能用于更新语句？答：会真实执行，必须遵循变更控制，通常不在生产直接使用。
- 追问：实际行数相同仍慢怎么办？答：查页命中、资源等待、网络传输和返回列宽度。
问题：Index Condition Pushdown（索引条件下推）怎样减少回表，它解决不了什么？
- 口述答案：索引条件下推的核心是把能够只依赖二级索引列判断的条件尽早交给存储引擎。以 (tenant_id,created_at,status) 为例，租户等值加时间范围能定位一个二级索引区间；状态位于范围列之后，通常不能继续缩小连续定位范围。没有下推时，引擎可能把范围内大量主键交给服务层回表后再判断状态；有下推时，先在二级叶页判断状态，只让符合条件的主键回表，因此减少随机读和聚簇页访问。它不等同覆盖索引：返回列不在二级叶页时仍要回表；它也不等同“后列重新参与定位”，范围内索引条目仍需扫描。若时间窗口本来就过大，下推只能减轻回表，不会消除扫描。设计上先让最能限制范围的等值和范围列进入正确前缀，再利用下推减少残余过滤；不要把函数、隐式转换或无法从索引值判断的条件期待成下推。验证时同时对比二级扫描量、回表量和实际节点耗时，而不是看到 Using index condition（使用索引条件下推）就停止分析。
- 详细章节与验证：本册 3.3：实际执行分析、额外信息与索引下推。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
- 追问：下推可替代覆盖索引吗？答：不能，前者减少不合格主键回表，后者直接免除所需列的回表。
- 追问：范围后列为何仍有价值？答：可做下推、覆盖、排序或分组的一部分，但不要夸大为定位前缀。
- 追问：如何确认收益？答：使用代表性参数比较实际回表与耗时，不只看计划文字。
问题：Multi-Range Read（多范围读取）和 Batched Key Access（批量键访问）分别解决什么问题？

口述答案：二级索引按二级键排序，查到的主键在聚簇索引页中未必连续；逐条回表会形成许多随机访问。Multi-Range Read（多范围读取）先积攒一批主键或范围，再按主键顺序访问聚簇页，利用页局部性减少随机读。Batched Key Access（批量键访问）把嵌套循环连接外表产生的一批连接键缓存起来，批量交给内表索引访问，并可借助 Multi-Range Read（多范围读取）改善内层回表。它们解决的是访问局部性和重复探测，不改变业务结果，也不自动修复错误的驱动顺序或缺失索引。代价是缓冲、批处理和返回节奏；在缓存很热或固态存储环境，收益仍须实测。排查连接慢时我先看外表经过过滤后的真实行数、内表连接键是否有索引、每个内层节点循环多少次；若外表意外放大百万倍，打开批量访问只是缓解症状。对 Runner（执行器）批量任务，我会先小批拿主键、再按主键批读详情，限制批次大小和超时，避免把巨大连接结果一次压进内存。
详细章节与验证：本册 4.1：MRR、BKA 与连接顺序。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：固态盘下是否无用？答：随机读惩罚降低但未消失，仍需量化验证。
追问：打开开关就一定启用吗？答：优化器仍按成本决定，版本和查询形状也有限制。
追问：能解决无索引连接吗？答：不能，缺失内表访问路径的根因仍在。

问题：两张大表连接时，怎样判断驱动表和连接顺序是否合理？

口述答案：我把连接成本拆为“外表过滤后行数 × 内表单次访问成本”。先确认每张表在真实参数下能过滤到多少，而不是用原始表大小判断；再确认被驱动表的连接键是否有可用索引，以及该索引是否还能同时满足额外过滤或覆盖。订单表 1000 万行，但日期和租户筛到 2 万；库存表 200 万行，仓库条件还剩 5 万。通常先驱动筛后的订单，再用仓库 + SKU（库存单位）精确找库存，比反过来让每个库存查历史订单更可控。但若订单条件很宽、库存条件极窄，顺序可能相反。优化器依赖统计，列相关性和倾斜会让它选错，所以我用实际计划关注每个节点的 loops（循环次数）和每次输出。修复优先级是补内表索引、缩小驱动集、把无谓的外连接或表达式改写掉，再考虑受控连接顺序 Hint（提示）。绝不把“表小先驱动”作为永恒规则；上线也要观察不同租户和日期分桶，防止头部客户改变选择性。
详细章节与验证：本册 4.1：MRR、BKA 与连接顺序。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：外表为什么会意外放大？答：条件失效、统计误判或连接前过滤未下推都会造成。
追问：小表能否驱动大表？答：可以，关键是过滤后基数和内表索引，不是表名大小。
追问：如何验证顺序改动？答：同参数比较实际循环、扫描量、临时结果和写侧影响。

问题：如何判断 Using temporary（使用临时表）和 Using filesort（使用文件排序）是否真是瓶颈？

口述答案：这两个标记都表示额外处理，但不是故障结论。临时表可能只物化几十个分组，也可能因巨大宽行溢出磁盘；文件排序表示不能直接按索引序输出，可能全在内存完成，也可能排序海量记录。我的第一步是定位它们前面的候选集：订单或轨迹在过滤、连接后还剩多少行，行宽是多少，最终只返回多少行。比如按 30 天异常轨迹聚合，先过滤 300 万行但只聚合为 80 个承运商，临时表的 80 行通常不是首要问题；若先连接出 5000 万宽行再排序，才是根因。优化手段包括让等值过滤前置、用联合索引匹配排序或分组顺序、只选择必要列、先分页后补详情、预聚合或异步统计。不能为了去掉一个标记添加很宽的索引，导致在线写轨迹每次维护成本上升。验证需要看实际节点耗时、排序行数、临时表磁盘指标、内存阈值和代表性参数，而不是只追求 Extra（额外信息）更短。
详细章节与验证：本册 4.2：临时表、filesort 与 Hash Join。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：文件排序一定写磁盘吗？答：不一定，取决于数据规模、行宽和可用内存。
追问：如何减少宽行排序？答：先选主键或排序键分页，再按主键补取详情。
追问：所有临时表都应消除吗？答：不应，小而可控的中间结果通常比宽索引更划算。

问题：MySQL（关系型数据库）8.0 的 Hash Join（哈希连接）出现后，连接索引还重要吗？

口述答案：仍然重要。Hash Join（哈希连接）适用于某些等值连接：数据库选择较小的构建输入建立哈希表，再扫描另一侧探测匹配项。它能避免某些场景下对内表做大量重复索引探测，但不会替代过滤、范围扫描、排序、分组和结果返回的索引需求。构建侧过大还会带来内存、分区和临时处理成本；非等值连接、需要保序输出或能用高选择性索引精确定位的场景，也不应期待它更优。版本边界必须讲准确：Hash Join（哈希连接）在 MySQL（关系型数据库）8.0.18 起引入，不能写到 5.7 或笼统说全部 8.0。我的做法是先用 EXPLAIN FORMAT=TREE（树形执行计划）和实际执行计划确认是否选中它，再对比两种计划下的实际行数、耗时、内存与并发表现；如果它被选中却慢，优先检查构建侧过滤是否足够、统计是否误判以及是否能把连接前的条件推早。不能因为有新算法就删掉订单、库存关联键上的索引。
详细章节与验证：本册 4.2：临时表、filesort 与 Hash Join。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：能用于所有连接吗？答：不能，适用性受等值谓词、版本和成本模型约束。
追问：如何选构建侧？答：通常选择过滤后较小输入，但由优化器与实际计划决定。
追问：为何索引仍必要？答：索引负责高选择性过滤、范围访问和排序等，哈希连接只覆盖一段连接工作。

问题：遇到优化器误判时，为什么不应第一时间 FORCE INDEX（强制索引）？

口述答案：FORCE INDEX（强制索引）会把今天观察到的分布和成本假设固化在 SQL（结构化查询语言）里。大促前待支付状态占 1%，状态索引可能很好；大促时占 55%，同一提示会强迫数据库走大量二级索引回表，反而比顺序扫描更慢。优化器误判的常见根因包括统计陈旧、采样没有表达倾斜、列相关性、隐式类型转换、参数范围变化和缓存冷热。正确顺序是先保全慢 SQL（结构化查询语言）、绑定参数、表定义、索引、统计更新时间、历史与当前计划，再用实际执行分析找到估算从哪一层开始失真。之后分别评估刷新统计、直方图、改写谓词、增加或调整联合索引、拆分过宽查询。只有业务已受影响、根因已经确认、替代修复来不及且已用代表性数据验证时，才把 Hint（提示）作为短期止血；同时设置生效范围、指标告警、到期时间和撤销条件。这样既能恢复服务，也不会让紧急补丁永久阻塞优化器适应新分布。
详细章节与验证：本册 4.3：优化器误判、Hint 与不可见索引边界。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：USE INDEX（建议索引）更安全吗？答：约束较弱但仍会影响选择，任何提示都要基于代表性验证。
追问：何时可以撤销提示？答：统计、索引或查询修复上线并在真实流量下稳定后撤销。
追问：提示能修复锁等待吗？答：它最多改变访问路径；锁根因还要在锁语义和事务边界中定位。

问题：不可见索引怎样用于索引下线和新索引验证？

口述答案：不可见索引是 MySQL（关系型数据库）8.0 的变更辅助能力。对准备删除的索引，先设为不可见，默认优化器不再把它作为候选路径；持续观察关键订单、库存和轨迹 SQL（结构化查询语言）的计划、扫描行数、延迟和错误率，确认没有隐藏依赖后再删除。它保留索引物理结构，因此隐藏期间仍占磁盘、仍有写入维护成本，不能把“设为不可见”当作治理完成。对新索引也可在受控会话中验证是否会被选择和是否改善计划，但生产默认不可见时不应误以为业务已经受益。5.7 没有这个功能，应借助只读副本、预发回放、影子流量和可回滚变更来验证。无论哪种版本，索引下线都要先盘点 SQL（结构化查询语言）来源，包括报表、定时任务、灰度接口和非常规租户；同时看写放大和空间回收窗口。最终标准不是“没有报错”，而是代表性参数下没有计划退化、在线写入没有异常，并且有恢复索引或切流回滚方案。
详细章节与验证：本册 4.3：优化器误判、Hint 与不可见索引边界。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：不可见是否等于删除？答：不是，物理索引仍存在并维护。
追问：如何覆盖低频 SQL（结构化查询语言）？答：结合慢日志、审计、任务清单和完整业务周期观察。
追问：新索引为何先不可见？答：可在受控范围验证计划，避免立即影响所有查询选择。

问题：请设计跨境物流轨迹表的索引与分页方案。

口述答案：我先按查询而不是按字段建模。轨迹明细通常以租户、运单号、发生时间、承运商、状态为主要条件；详情查询按运单号与时间正序，运营列表按租户、时间范围、异常状态倒序，不能用一个超宽索引兼顾全部。对于列表，我会明确查询窗口，例如近 30 天，使用租户等值 + 时间范围作为主要定位前缀，再根据异常状态、排序和返回列验证联合索引顺序；若状态位于范围后，可用于索引条件下推和覆盖，但不应宣称继续缩小定位区间。分页采用 event_time（发生时间）与唯一主键组成全序游标，下一页严格从上一条之后读，避免偏移扫描百万历史记录。运单号若需要前缀检索，先量化前缀选择性；任意子串搜索则评估检索系统，不能拿 %关键字%（任意位置匹配）压数据库。数据长期增长时还需按时间归档并限制在线查询跨度。验证指标包括实际扫描行数、回表、排序、最深游标、头部承运商倾斜和写入索引成本；出问题时保留参数分桶，防止某个大客户或补写历史轨迹使计划漂移。
详细章节与验证：本册 2.4：排序、分组、降序与深分页。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：为何主键要加入游标？答：为同一时间的多条记录建立稳定全序。
追问：历史补写怎么办？答：定义查询快照上界或水位，明确浏览集合的时间边界。
追问：运单号任意搜索怎么办？答：评估专用全文或倒排检索，不强迫 B+Tree（多路平衡树）承担。

问题：WMS（仓储管理系统）库存 SKU（库存单位）查询怎样兼顾列表、单条查询和防超卖？

口述答案：库存表首先要把“读取路径”和“扣减正确性”分开。单条库存以仓库 + SKU（库存单位）精确定位，应该有业务唯一约束或相应联合索引；仓内库存列表则需要仓库等值、SKU（库存单位）或更新时间排序的访问路径，必要时只覆盖列表展示列。库存防超卖不能依赖“索引很快”，而要用条件更新，例如可用量足够才扣减，检查受影响行数，并结合订单幂等标识、状态机和后续对账。索引的作用是让当前读精确定位，避免无关扫描并减少潜在锁范围；若没有合适索引，性能和并发影响都会扩大，但锁细节由锁章节继续说明。对于低库存筛选，available_qty（可用量）通常是范围条件，不能盲目放在联合索引前面破坏仓库和 SKU（库存单位）访问；应按真正的筛选、排序、频率和结果量设计。列表使用游标分页，批量补货或 Runner（执行器）任务采用小批主键扫描，避免深偏移。验证时既看查询扫描和延迟，也看扣减失败率、重复请求、写入吞吐和索引大小，确保读优化没有把写热点放大。
详细章节与验证：本册 2.3：联合索引、最左前缀与范围截断。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：低库存范围查询是否一定加数量索引？答：看仓库、SKU（库存单位）与时间条件后的候选量，单列范围未必划算。
追问：唯一索引还能做什么？答：表达业务不变量并支撑精确定位，不替代条件更新。
追问：批量盘点如何读？答：按稳定主键或分区间小批处理，避免长事务和全表导出。

问题：支付对账列表为什么要区分在线查询、详情和导出？

口述答案：三个场景的访问形状不同。在线列表追求低延迟，字段应固定为支付单号、状态、金额、渠道流水号和发生时间，围绕租户、对账日、状态和排序设计窄联合索引，尽量覆盖返回列；详情查询按支付主键回表读取敏感字段；全量导出则不应借用在线列表的深分页，而要在固定时间边界上异步分批、游标读取、限速写文件。若把三者混为一个 SELECT *（查询全部列）接口，列表会产生大量回表和网络传输，导出还会造成连接占用、缓存抖动与长时间扫描。对账条件常有渠道、状态等低基数列，必须与租户、日期等高约束条件组合判断选择性。发生慢查询时，我会对比不同渠道、日期和状态参数的计划，尤其看统计是否低估头部渠道；不能只凭一次正常参数建索引。优化后要验证列表 p95（第 95 百分位）、导出吞吐、数据库写延迟和账务结果一致性；数据正确性仍由唯一约束、幂等、状态机和对账补偿保障，索引只负责让访问路径可控。
详细章节与验证：本册 2.2：聚簇索引、二级索引、回表与覆盖。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：导出能直接跑主库吗？答：应评估隔离、副本、限速和一致性边界，不能无控制重查询主库。
追问：对账日跨天如何分页？答：固定查询上界并用时间 + 主键游标，避免新数据插入扰乱集合。
追问：列表覆盖索引是否含敏感字段？答：只含必要展示列，敏感详情按权限与主键再取。

问题：如何解释 type（访问类型）很差但查询仍然合理？

口述答案：访问类型是计划标签，不是性能评分。小维表只有几百行，ALL（全表扫描）读取全表可能比维护和随机访问一个低选择性索引更便宜；统计报表本来要读大部分历史记录时，顺序扫描也合理。反过来，ref（非唯一等值访问）如果命中数十万、还要逐行回表和排序，未必快。所以我的判断标准是查询目标与成本是否匹配：预计返回多少、实际扫描多少、是否高并发、是否占用共享缓存、是否拖慢写入。index（全索引扫描）在覆盖窄索引时可能优于读完整表，但若扫描后仍大量回表则可能更差。对订单、库存、轨迹等核心接口，我会设扫描行数和延迟预算，把大于预算的参数分桶报警；对离线统计，则通过副本、限速、时间窗口和异步化控制影响。这样面试时既能说明常见访问类型的大致精确程度，也不会把优化简化成“消灭 ALL（全表扫描）”。
详细章节与验证：本册 3.2：成本模型、访问类型与执行计划。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：const（常量访问）总是最快吗？答：单表定位很精确，但端到端耗时还包含连接、返回与网络。
追问：何时全索引扫描有收益？答：窄覆盖索引能避免读取宽行且确实需要扫多数记录时。
追问：优化阈值如何定？答：由并发、SLO（服务等级目标）、表量和资源预算共同定义。

问题：怎样从一次订单列表事故中定位“索引存在但仍慢”的原因？

口述答案：先止血：限制异常日期跨度、深分页和超大页大小，对热点租户做降级或异步导出，避免单条慢 SQL（结构化查询语言）拖垮连接池。取证时保留完整 SQL（结构化查询语言）、绑定参数、表定义、索引、执行计划、慢日志时间、表行数、统计更新时间和数据库资源指标。然后比对历史与当前计划：索引是否真的被选中，rows（预估扫描行数）和 filtered（过滤百分比）是否说明早期过滤失效，Extra（额外信息）是否出现回表、排序或临时表。用安全环境的实际执行分析确认扫描、循环和耗时，区分统计误判、某租户数据倾斜、隐式转换、范围过宽、覆盖缺失或连接顺序放大。修复不是默认加索引：可能是把日期改为原列范围、补租户前缀、改成游标、拆列表与详情、刷新统计或为连接内表补索引。上线后用同量级回放和灰度观察 p95（第 95 百分位）、扫描行数、写入延迟、缓存命中与磁盘空间；保留回滚路径。复盘再把参数分桶和计划漂移纳入监控，避免下次只在头部租户爆发时才发现问题。
详细章节与验证：本册 4.4：线上证据模型与项目话术。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：为什么先限制分页？答：它是可逆止血，能立即减少扫描与排序放大。
追问：什么时候刷新统计？答：确认分布变化且有受控窗口后，不把它作为盲目第一步。
追问：怎样验证无回归？答：覆盖典型、长尾和头部租户参数，同时监控写侧。

问题：一个订单表索引很多，如何做索引治理而不误删？

口述答案：索引治理的目标是移除无收益或重复维护成本，不是追求索引数量最少。先建立清单：每个索引的定义、大小、写入代价、对应 SQL（结构化查询语言）和使用频率；特别识别左前缀重复，例如 (a,b,c) 是否已覆盖 (a,b) 的主要读取，但也要注意排序方向、覆盖列和独立统计场景可能不同。然后从慢日志、性能模式、报表和定时任务收集完整业务周期，不能只看白天接口。MySQL（关系型数据库）8.0 可先把候选索引设为不可见，观察默认计划是否退化；5.7 则在副本或影子流量验证。任何删除前都要检查唯一约束和外键语义，唯一索引即使读频率低也可能是业务正确性保障。新增索引同样需要证明它降低了实际扫描或排序，并观察写延迟、页分裂、空间和备份时间。最终以灰度、可恢复 DDL（数据定义语言）方案和指标阈值完成，而不是在事故现场一次删除多个索引。治理过程必须记录每个索引的所有者和回滚条件，避免新需求恢复旧查询时没人知道设计理由。
详细章节与验证：本册 4.3：优化器误判、Hint 与不可见索引边界。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：联合索引总能替代短前缀索引吗？答：常可覆盖访问前缀，但需核对排序、覆盖和实际计划。
追问：唯一索引为何不能只按使用次数删？答：它可能承担业务不变量和幂等约束。
追问：如何评估写成本？答：看写延迟、索引页大小、分裂、日志和磁盘增长。

问题：前缀索引、函数索引和降序索引有哪些版本与业务边界？

口述答案：前缀索引用于长字符串列，只保存前 N 个字符，能减小索引体积，但 N 过短会造成大量同前缀误命中与回表，且通常不能完整覆盖原列或满足完整排序。设计时应比较不同 N 的不同值比例和真实查询扫描量。普通索引按原始列值排序，若在谓词中对列施加日期、大小写或其他函数，往往失去可搜索范围；MySQL（关系型数据库）8.0 可在适当版本和确定表达式条件下使用函数索引或生成列索引，但要把表达式、写入维护、空值与迁移兼容性讲清，不能只为绕过查询改写而堆索引。降序索引是 8.0 的能力，尤其用于混合排序方向；5.7 不能照搬其计划预期。三者都要回到业务问题：轨迹号前缀搜索、按天汇总、倒序列表分别需要不同结构；任意子串搜索、复杂文本相关性则应评估专用检索。上线前必须用实际小版本验证计划，并量化索引体积、写入和回表，避免把新特性当成无成本语法糖。
详细章节与验证：本册 2.3：联合索引、最左前缀与范围截断。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：前缀长度越长越好吗？答：选择性更好但索引更大，应找满足查询的平衡点。
追问：函数索引能用于所有函数吗？答：要受版本、表达式确定性和语义一致性限制。
追问：5.7 如何处理混合倒序？答：重审查询与索引，不能假设 8.0 的降序叶页能力存在。

问题：如何为优化器建立长期可观测性，而不是等慢 SQL（结构化查询语言）报警？

口述答案：我会把“接口延迟”拆成可比较的查询证据。第一层按 SQL（结构化查询语言）指纹统计调用量、p50（第 50 百分位）/p95（第 95 百分位）/p99（第 99 百分位）、错误与超时；第二层按参数维度分桶，例如租户、日期跨度、分页深度、状态和承运商，避免平均值掩盖头部客户；第三层采样保存计划摘要，包括实际索引、预估扫描、排序临时表和连接顺序；第四层在安全环境周期性执行代表性参数的实际分析，记录估算与实际行数比例。数据库侧再关联索引大小、缓冲池命中、临时表落盘、排序行数、磁盘队列和连接等待。告警不应只设“慢于一秒”，还要检测计划突变、扫描行数陡增、估算误差超过阈值和深分页请求。发生变更时将索引、统计和版本变更与计划时间线关联，才能快速判断是数据分布、代码发布还是资源问题。这样的体系也能约束 Hint（提示）：每个提示必须有命中指标和到期复核。最终目标是把索引优化从人工猜测变成有参数、有计划、有实际行数和有回滚证据的工程流程。
详细章节与验证：本册 4.4：线上证据模型与项目话术。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：为何要参数分桶？答：同一 SQL（结构化查询语言）不同租户或时间范围的选择性可能完全不同。
追问：能频繁在线运行实际分析吗？答：要受控，因为它会执行查询；优先副本或回放环境。
追问：计划变化必然故障吗？答：不必然，但应结合扫描量与延迟判断是否退化。

问题：请用三分钟串讲订单、库存和轨迹场景下的索引优化方法论。

口述答案：我的方法论是先固定业务语义，再设计访问路径，最后用实际证据验证。订单列表先确定租户、时间、状态、稳定排序与必要展示列，联合索引按等值前缀、范围、排序和覆盖取舍设计，深分页使用时间 + 主键游标；详情按主键回表，导出异步分批。库存场景中，仓库 + SKU（库存单位）唯一约束或精确索引负责定位，列表按仓和编码或更新时间走另一访问路径；防超卖由条件更新、受影响行数、幂等和对账保证，不能把索引误说成并发正确性。轨迹表增长快，索引先服务租户、时间窗口和运单查询，前缀搜索量化选择性，任意子串交给更合适的检索能力，历史数据归档；分页同样使用全序游标。优化器层面，我用 EXPLAIN（执行计划）看访问方法、预估扫描和附加排序，用实际执行分析对照真实行数和循环，重点识别统计陈旧、倾斜、列相关性、回表和连接放大。Using temporary（使用临时表）与 Using filesort（使用文件排序）只作为证据，不是罪名；Hint（提示）只作短期、可撤销兜底。每次索引变更都验证读延迟、扫描量、写入代价、空间和长尾参数，并保留回滚。这套方法既能回答原理，也能落到 WMS（仓储管理系统）、支付和跨境物流的线上决策。
详细章节与验证：本册 4.4：线上证据模型与项目话术。复核要覆盖代表参数的扫描行数、返回行数、节点耗时、写入延迟、索引空间、缓存命中和回滚阈值；还要在高峰和低峰、头部与普通租户、浅页与深页各复跑一次，只有读延迟下降且写入、空间、等待均不恶化，才可推广。
追问：先加索引还是先看计划？答：先理解查询语义和实际计划，避免新增无收益索引。
追问：如何处理版本差异？答：明确 5.7、8.0、8.4 和小版本边界，再实测验证。
追问：优化成功的唯一指标是什么？答：没有唯一指标，应同时验证延迟、扫描、写成本与业务正确性。

6. 本册复习清单

你能用页扇出计算 B+Tree（多路平衡树）三层可容纳的数量级，并说明缓存命中会改变 I/O（输入输出）成本。
你能区分聚簇索引、二级索引、回表、覆盖索引和索引条件下推的各自边界。
你能用一个库存联合索引解释最左前缀、第一个范围和后列下推。
你能区分 EXPLAIN（执行计划）的估算与 EXPLAIN ANALYZE（实际执行分析）的真实执行成本。
你能用 rows（预估扫描行数）乘 filtered（过滤百分比）推断下游连接风险。
你能解释 Multi-Range Read（多范围读取）、Batched Key Access（批量键访问）、Nested Loop Join（嵌套循环连接）和 Hash Join（哈希连接）的适用边界。
你能说明临时表、filesort（文件排序）不是绝对坏信号，并能用中间结果规模判断优先级。
你能在订单、库存 SKU（库存单位）和轨迹分页三个场景中给出索引、游标和验证指标。
你能说明 Hint（提示）、不可见索引和统计刷新是受控工具，不是替代模型设计的万能修复。

7. 本册交付自检

项目	本册数量	验收说明
`kb:knowledge`（知识条目）	11	每条紧跟知识型三级标题，且均有章节题
六字段章节题	33	11 个知识条目 × 基础、原理、项目三题
Mermaid（图表语法）图	12	每图均在紧邻正文解释节点、前提与失败边界
表格	11	覆盖版本、执行计划、项目取舍与验收
数据演绎	10	覆盖扇出、回表、选择性、分页、统计、估算、下推、连接、排序和 Hint（提示）
综合长答案	24	每题一个 560—900 字左右的口述答案、回链与 3 个追问

版本与事实边界：本册以 MySQL（关系型数据库）5.7、8.0、8.4 为表达范围；EXPLAIN ANALYZE（实际执行分析）和 Hash Join（哈希连接）均按 MySQL（关系型数据库）8.0.18 起讨论；降序索引、不可见索引与直方图限于 MySQL（关系型数据库）8.0 及以上。具体生产小版本、配置和成本模型必须以当前实例实测及官方手册为准。

1.5.2 B+Tree（多路平衡树）索引与优化器

1.5.2 B+Tree（多路平衡树）索引与优化器

1. 学习目标、边界与版本口径

2. B+Tree（多路平衡树）的页、层高与结构维护

2.1 页扇出、层高与叶页链表

热门面试题

2.2 聚簇索引、二级索引、回表与覆盖

热门面试题

2.3 联合索引、最左前缀与范围截断

热门面试题

2.4 排序、分组、降序与深分页

热门面试题

3. 优化器：统计信息、成本与执行证据

3.1 统计信息、基数与直方图

热门面试题

3.2 成本模型、访问类型与 `EXPLAIN`（执行计划）

热门面试题

3.3 `EXPLAIN ANALYZE`（实际执行分析）、`Extra`（额外信息）与索引下推

热门面试题

4. 连接、排序与优化器的执行选择

4.1 MRR（多范围读取）、BKA（批量键访问）与连接顺序

热门面试题

4.2 临时表、filesort（文件排序）与 Hash Join（哈希连接）

热门面试题

4.3 优化器误判、Hint（提示）与不可见索引边界

热门面试题

4.4 线上证据模型与项目话术

热门面试题

4.5 综合题库过渡（非知识型）

5. 综合面试题与追问

6. 本册复习清单

7. 本册交付自检

1.5.2 B+Tree（多路平衡树）索引与优化器

1. 学习目标、边界与版本口径

2. B+Tree（多路平衡树）的页、层高与结构维护

2.1 页扇出、层高与叶页链表

热门面试题

2.2 聚簇索引、二级索引、回表与覆盖

热门面试题

2.3 联合索引、最左前缀与范围截断

热门面试题

2.4 排序、分组、降序与深分页

热门面试题

3. 优化器：统计信息、成本与执行证据

3.1 统计信息、基数与直方图

热门面试题

3.2 成本模型、访问类型与 EXPLAIN（执行计划）

热门面试题

3.3 EXPLAIN ANALYZE（实际执行分析）、Extra（额外信息）与索引下推

热门面试题

4. 连接、排序与优化器的执行选择

4.1 MRR（多范围读取）、BKA（批量键访问）与连接顺序

热门面试题

4.2 临时表、filesort（文件排序）与 Hash Join（哈希连接）

热门面试题

4.3 优化器误判、Hint（提示）与不可见索引边界

热门面试题

4.4 线上证据模型与项目话术

热门面试题

4.5 综合题库过渡（非知识型）

5. 综合面试题与追问

6. 本册复习清单

7. 本册交付自检

3.2 成本模型、访问类型与 `EXPLAIN`（执行计划）

3.3 `EXPLAIN ANALYZE`（实际执行分析）、`Extra`（额外信息）与索引下推