- 正确答案：MyBatis 动态 SQL 标签主要包括 if、choose（when/otherwise）、trim（where/set）、foreach、bind、script 等；而“精准命中索引”并非 MyBatis 本身的功能，而是依赖于其生成的 SQL 是否满足数据库索引使用条件（如最左前缀原则、避免隐式类型转换、避免在索引列上使用函数或表达式等），需结合 SQL 写法、表结构、索引定义及执行计划综合判断与优化。 - 解答思路：第一步，明确 MyBatis 动态 SQL 标签的语义和典型用途，理解它们如何生成最终可执行的 SQL；第二步，指出索引命中是数据库查询优化器的行为，MyBatis 只负责拼装 SQL，不参与执行计划生成；第三步，分析哪些动态 SQL 写法容易导致索引失效（如在 if 中拼接 OR 条件破坏索引范围扫描、用 like '%xxx' 导致全表扫描、foreach 生成 IN 列表但参数过多触发临时表或全表扫描等）；第四步，给出保障索引命中的实践策略：SQL 结构可控 + 索引设计合理 + 执行计划验证（EXPLAIN）+ 参数绑定规范。 - 深度知识讲解：【1】MyBatis 动态 SQL 标签底层原理： MyBatis 在启动时将 XML 中的、等标签解析为 SqlNode 树，运行时根据参数对象（ParameterMap）动态遍历 SqlNode，调用其 apply() 方法生成 BoundSql。例如： - AND name = #{name} → 对应 IfSqlNode，内部通过 OGNL 表达式引擎（ognl.jar）解析 test 属性，再调用 ExpressionEvaluator.evaluateBoolean() 判断是否追加该 SQL 片段； - #{id} → 对应 ForEachSqlNode，遍历 ids 集合，逐个渲染 #{id} 占位符（本质是 PreparedStatement 的 ? 参数绑定），最终生成形如 AND id IN (?, ?, ?) 的 SQL；所有动态标签最终都编译为字符串拼接逻辑（非 SQL 注入风险，因 #{} 是预编译占位符），但拼接结果是否符合索引使用条件，完全取决于开发者对 SQL 语义的理解。【2】索引命中核心机制（以 MySQL InnoDB 为例）： - B+Tree 索引查找依赖「索引有序性」和「最左前缀匹配」：WHERE a=1 AND b>2 AND c=3 仅能利用 (a,b,c) 复合索引的 a 和 b（b 是范围查询，c 被截断）； - 索引失效常见场景： • 在索引列上使用函数：WHERE YEAR(create_time) = 2024 → 无法走 create_time 索引； • 隐式类型转换：WHERE mobile = 13800138000（mobile 是 VARCHAR）→ MySQL 将数字转为字符串比较，但可能放弃索引（取决于字符集和 collation）； • LIKE 左模糊：WHERE name LIKE '%java' → 全表扫描； • OR 连接非全索引字段：WHERE a = 1 OR b = 2（仅 a 有索引）→ 可能放弃索引走全表； • 使用 != 或 NOT IN（尤其子查询时易转为全表）； • WHERE 子句中对索引列进行数学运算：WHERE score + 10 > 90。【3】MyBatis 动态 SQL 与索引命中的关键交点： ▶️ trim + where 标签的自动去首 AND/OR 是安全的，不影响索引； ▶️ if 标签若生成 OR 条件（如 status = 1 status = 2 ），实际拼出 WHERE status = 1 OR status = 2，仍可走 status 索引（等值 OR 可被优化器转为 UNION）；但若混用 AND/OR 无括号约束（如 AND (a=1 OR b=2)），需注意括号缺失导致逻辑错误进而影响索引选择； ▶️ foreach 生成 IN 列表：IN (?) 形式天然支持索引（MySQL 5.7+ 对 IN 列表做 range 访问），但若集合过大（如 10w 个 ID），InnoDB 可能退化为全表扫描或使用临时表（可通过 optimizer_switch='range_optimizer_max_mem_size=8388608' 控制）；建议分页批量处理； ▶️ bind 标签可用于预计算： WHERE name LIKE #{pattern} → 此写法虽避免 Java 层拼接，但仍为右模糊，仅当 name 建立了前缀索引（如 INDEX(name(10))）且 keyword 较短时才可能部分利用；真正高效应改用全文索引或 ES； ▶️ script 标签（用于注解 @SelectProvider）需极度谨慎：它直接内联 SQL 字符串，若含 ${} 拼接，既危险（SQL 注入）又不可控（无法保障索引）。【4】验证与保障手段： - 开发阶段：开启 MyBatis 日志（log4j.logger.org.apache.ibatis=DEBUG）查看真实执行 SQL； - 数据库侧：对生成的 SQL 执行 EXPLAIN FORMAT=TREE / EXPLAIN ANALYZE（MySQL 8.0.18+）观察 key、key_len、rows、filtered、Extra 字段；关键指标： • key != NULL → 确实走了索引； • key_len 应等于预期索引字节数（如 utf8mb4 字符集 VARCHAR(50) 索引长度 = 50×4 = 200）； • type = range/ref/eq_ref → 合理；type = ALL/INDEX → 全表/全索引扫描，需优化； • Extra 中出现 Using filesort / Using temporary → 排序/分组未走索引，性能瓶颈； - 建议建立「SQL 审核规范」：禁止在索引字段上使用函数、禁止无 LIMIT 的大结果集查询、IN 列表长度阈值控制（如 ≤ 1000）、复合索引字段顺序按查询频率和选择性降序排列。 - 伪代码/示例说明：假设用户表 user(id PK, name VARCHAR(50), age TINYINT, city VARCHAR(20))，已建复合索引 IDX_NAME_AGE_CITY(name, age, city)。 ✅ 安全写法（精准命中索引）： ```xml ``` → 优化建议：将条件顺序改为 name → city → age，或新建覆盖索引 IDX_NAME_CITY_AGE； ❌ 危险写法（索引失效）： ```xml AND name LIKE CONCAT('%', #{nameLike}, '%') AND age = #{ageStr} ``` ✅ 替代方案（函数索引 + 类型强一致）： MySQL 8.0+ 可建函数索引： CREATE INDEX IDX_NAME_LOWER ON user ((LOWER(name))); 对应 SQL：AND LOWER(name) = LOWER(#{name}) → 可走该索引；同时 Java 中确保 age 参数为 Integer 类型，避免 String 传参。综上，MyBatis 动态 SQL 是“手”，索引是“靶”，能否命中不取决于手多灵巧，而在于是否瞄准了靶心——即 SQL 语义是否严格符合索引的 B+Tree 查找规则。掌握 OGNL 表达式求值机制、InnoDB 索引访问路径、执行计划解读三者交叉知识，才是校准“动态 SQL → 精准索引”的核心技术能力。

快手日常实习二面

全站热榜

创作者周榜