- 正确答案：会走 (a,b,c) 联合索引，但仅能**有效利用最左前缀 a 和 b**，c 字段在该查询条件下**无法用于索引范围扫描的右边界裁剪（即不能高效过滤 c<3）**，但依然可能参与索引过滤（取决于 MySQL 版本和优化器决策）。严格来说：该查询可使用 (a,b,c) 索引进行 **Index Range Scan**，其索引扫描范围是 a=1 AND b>2 的子树内所有记录，然后对这些记录逐行回表或直接在索引中检查 c<3 条件（若为覆盖索引则无需回表）；c 字段不参与“索引查找路径”的构造，但参与“索引过滤”（ICP，Index Condition Pushdown）。 - 解答思路：判断联合索引能否被使用，核心依据是 **最左前缀原则（Leftmost Prefix Principle）**。MySQL 的 B+ 树索引按字典序存储键值，(a,b,c) 索引的物理排序顺序是先按 a 升序，a 相同时按 b 升序，b 也相同时按 c 升序。查询条件为 a=1 AND b>2 AND c<3： • a=1 → 可定位到索引中所有 a=1 的数据页/节点（等值匹配，可精确跳转）； • b>2 → 在 a=1 的子树内，可进一步用 b 做范围扫描（从第一个 b>2 的记录开始向右遍历）； • c<3 → 此时已处于 a=1 且 b>2 的连续索引片段中，但 c 在该片段内**不再有序**（因为 b 是第二级排序键，c 仅在相同 a 和相同 b 下才有序），所以无法用 c 构造新的范围下界/上界来跳过数据块；即：c<3 不能减少索引扫描的起始/结束位置，只能作为**逐行过滤条件**。因此，索引扫描范围是：所有满足 a=1 且 b>2 的索引项（无论 c 值如何），再在这些项中筛选出 c<3 的行。 - 深度知识讲解： 1. **B+ 树联合索引存储结构**： (a,b,c) 索引的每个叶子节点存储完整键值 (a_i, b_j, c_k) + 主键（或行指针）。逻辑上构成一棵三维字典序树。物理上，B+ 树按 (a,b,c) 元组整体排序，因此 (1,2,5)、(1,2,1)、(1,3,0)、(1,3,9) 是按此顺序排列的。注意：(1,2,5) 和 (1,2,1) 中 c 有序，但 (1,2,5) 和 (1,3,0) 之间 c 完全无序。 2. **最左前缀匹配与范围中断（Range Access Method）**： MySQL 使用“range”访问类型时，会构建一个索引区间 [low_key, high_key] 进行扫描。对于 WHERE a=1 AND b>2 AND c<3： • low_key = (1,2,−∞) —— 注意：b>2 是开区间，实际取 b 的下一个最小值（如 b 是整型，则为 b≥3），故 low_key ≈ (1,3,−∞)； • high_key = (1,+∞,+∞) —— 因为 b>2 无上界，c<3 也无法提供 b 维的上界，所以 high_key 实际由 b 决定为 (1,+∞)，c 不参与 high_key 构造。最终扫描区间是 (a,b) 平面上满足 a=1 ∧ b>2 的所有索引条目，c 不缩小该区间。 3. **ICP（Index Condition Pushdown）优化（MySQL 5.6+）**：若启用了 ICP（默认开启），优化器会将 c<3 下推到存储引擎层，在读取索引项时就判断 c 字段是否满足，避免回表后再过滤。这意味着即使 c 未参与范围界定，仍能减少回表次数或无效行处理。可通过 EXPLAIN 中的 Extra 字段查看是否出现 "Using index condition"。 4. **对比其他条件组合**： • WHERE a=1 AND b=2 AND c<3 → 全部命中，c 可用于范围扫描（因 a,b 等值后，c 自然有序），扫描区间为 (1,2,−∞) 到 (1,2,3)； • WHERE a=1 AND c<3 → 仅 a 有效，b 和 c 都无法利用（b 缺失导致 c 失去有序性），此时 b 成为“断点”，c 完全失效； • WHERE b>2 AND c<3 → a 缺失，联合索引完全不可用（除非有单独 b 索引），因不满足最左前缀。 5. **索引选择与成本估算**：即使 (a,b,c) 可用，优化器仍可能选择全表扫描，如果预估满足 a=1 AND b>2 的行数占比过大（例如 b>2 覆盖 80% 数据），此时索引扫描+回表的成本 > 全表扫描。可通过 ANALYZE TABLE 更新统计信息，或强制使用索引（USE INDEX）验证。 - 伪代码/执行流程示意（存储引擎层）： ``` // 假设使用 InnoDB，(a,b,c) 是二级索引（非聚簇） cursor = index_seek_first(leaf_node_of_index, key_low=(1,3,-inf), key_high=(1,+inf,+inf)) while cursor.valid() do: entry = cursor.read_entry() // 读取索引项：(a,b,c,primary_key) if entry.c < 3 then // ICP：在引擎层过滤 c if need_full_row then row = innodb_read_row_by_pk(entry.primary_key) output(row) else output(entry) // 覆盖索引场景 cursor.next() ``` - 补充说明（易错点）： • “走索引” ≠ “全部条件都用于索引查找”。只要最左前缀中首个等值列存在，且后续列未被范围条件中断（如 a=1 AND b>2 中，a 是等值，b 是范围，此时 b 是最后一个可参与扫描的列），则索引可用，但仅至此为止。 • c<3 在 (a,b,c) 索引中属于“index filter”，而非“index condition for range scan”。这是理解执行计划的关键分水岭。 • 若业务中高频出现 a=1 AND b>2 AND c<3 类查询，更优索引设计可能是 (a,b) 作为联合索引（精简），再配合 c 的单独索引（供其他查询用），或考虑 (a,b,c) 索引 + 覆盖查询避免回表。 - 验证方式（实操建议）：执行 EXPLAIN FORMAT=TRADITIONAL SELECT * FROM t WHERE a=1 AND b>2 AND c<3; 关注： type: 'range'（表明用了索引范围扫描） key: '(a,b,c)' rows: 预估扫描行数（应远小于全表行数） Extra: 含 'Using index condition' 表示 ICP 生效；若为 'Using where' 则 c 过滤在 server 层完成（效率较低）。

美团一面（挂）

全站热榜

创作者周榜