索引失效本质是sql写法或参数类型不匹配导致mysql优化器放弃索引，而非java问题；需严格遵循最左前缀原则、避免函数操作、确保参数类型与字段一致、禁用左模糊查询。
Java 中调用 MySQL 时，索引失效导致聚簇索引退化为全表扫描，本质不是 Java 的问题，而是 SQL 写法或参数传递方式触发了 MySQL 优化器放弃索引。关键在于：Java 层生成的 SQL 必须满足 MySQL 索引使用条件，同时参数类型、值格式必须与字段定义严格一致。
确保 WHERE 条件严格匹配索引结构
联合索引（如 (user_id, status, create_time)）必须遵循最左前缀原则。Java 中拼接或构造查询时，不能只传 status = 'paid' 或 create_time > ? 就执行，否则跳过左侧列，索引完全失效。
- ✅ 正确：查询中包含最左列
user_id = ?，再叠加后续条件 - ❌ 错误：仅用
status = ? AND create_time > ?—— 即使有索引也走全表扫描 - ? 建议：在 MyBatis Mapper XML 或 QueryDSL 中显式校验必填驱动字段；Spring Data JPA 自定义查询方法名需以索引最左列开头（如
findByUserIdAndStatusIn）
禁止在索引列上做函数或表达式操作
Java 代码中若把函数逻辑写进 SQL（如 WHERE DATE(create_time) = ?），MySQL 无法利用 create_time 上的索引。即使该字段是主键或聚簇索引的一部分，也会强制全表扫描。
- ✅ 正确：用范围代替函数，例如传入两个 LocalDateTime 参数：
create_time >= ? AND create_time - ❌ 错误：用
UPPER(name) = ?查询带索引的name字段 - ? 补充：MySQL 8.0+ 可建函数索引（
CREATE INDEX idx_name_upper ON t ((UPPER(name)))），但 Java 调用时仍需保持左侧纯列名（WHERE UPPER(name) = ?才能命中）
严格对齐字段类型与 Java 参数类型
隐式类型转换是最隐蔽的索引杀手。比如数据库字段是 VARCHAR(20) 的订单号 order_no，Java 用 Long 类型传参（query.setParameter("orderNo", 12345L)），MySQL 会把整数转成字符串比较，触发全表扫描。
- ✅ 正确：字符串字段一律用
String传参，整型主键不用引号但类型必须是Integer/Long - ❌ 错误：
WHERE order_no = 12345（字段 varchar，参数 long）→ 隐式转换 → 索引失效 - ? 提示：JDBC 驱动日志（启用
useSSL=false&logger=com.mysql.cj.log.StandardLogger&profileSQL=true）可观察实际发送的 SQL 和参数类型
避免模糊查询破坏索引有序性
LIKE '%关键词' 会让任何前缀索引失效，聚簇索引也无济于事。Java 层若未做前置校验，用户搜“abc”却传 %abc%，就会扫完整张表。
- ✅ 正确：前端限制搜索模式，后端拦截并拒绝前导 %；支持前缀搜索用
LIKE 'abc%' - ❌ 错误：通用模糊查询接口直接拼接
LIKE CONCAT('%', ?, '%') - ? 替代方案：对高频模糊需求，Java 可集成 Elasticsearch，或 MySQL 内建全文索引（
MATCH ... AGAINST），不依赖 B+ 树顺序
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
