MySQL中!=和IS NULL不利于索引利用，优化应绕过低效本质：!=改用IN枚举或正向筛选，IS NULL需确保字段有索引且避免跨列OR，Java层应控制字段选择、动态拼接及NULL语义统一。
MySQL 中 !=（或 <>）和 IS NULL 这两类条件在 Java 应用中常被用于动态查询，但它们天然不利于索引利用。优化的关键不是“强行让 != 走索引”，而是绕过它的低效本质，改用可索引的等价逻辑，并配合 Java 层合理构造 SQL。
不等于（!= / <>）查询的优化思路
col != 'X' 无法走 B+ 树索引的等值定位，因为结果集是离散、非连续的；优化器通常放弃索引，直接全表扫描。
✅ 可行策略：
-
枚举替代（IN 拆解）
仅适用于取值极少的字段（如 status 只有'A','B','C'）：-- ❌ 低效 WHERE status != 'A' -- ✅ 可走索引（type=range） WHERE status IN ('B', 'C')Java 中可用
List<String> validStatuses = Arrays.asList("B", "C");动态拼接IN子句，避免硬编码。立即学习“Java免费学习笔记（深入）”；
-
排除法转正向筛选
如果业务允许，把“排除某类”改为“明确包含几类”：// 原逻辑：查所有非禁用用户 where += " AND state != 'DISABLED'"; // 优化后：只查启用/待审核（假设只有这几种合法状态） where += " AND state IN ('ACTIVE', 'PENDING')"; -
覆盖索引 + 明确 SELECT 字段
即使用了IN，若写SELECT *，仍可能因回表代价高而弃用索引。Java 中应严格限制返回字段：String sql = "SELECT id, name, state FROM user WHERE state IN (?, ?)"; // 配合联合索引 (state, id, name) 实现覆盖扫描
⚠️ 注意：!= 对 NULL 无效（col != 'X' 自动过滤掉 NULL 行），需额外处理。
IS NULL 查询的优化要点
IS NULL 是少数能走索引的“空值判断”，MySQL 对其做了专门优化（ref_or_null 访问类型），但前提是字段有索引且允许 NULL。
✅ 确保高效执行：
-
字段必须有索引
单列索引即可支持IS NULL快速定位：CREATE INDEX idx_updated_at ON orders(updated_at); -- ✅ 下面会走索引 SELECT id FROM orders WHERE updated_at IS NULL;
避免混合 NULL 判断引发索引失效
WHERE col = ? OR col IS NULL可走ref_or_null，但WHERE col IS NULL OR col2 = ?（跨列 OR）大概率退化为全表扫描。Java 构建条件时，尽量把IS NULL和等值条件放在同一字段上。-
用覆盖索引减少回表
-- 建立覆盖索引 CREATE INDEX idx_user_status_id ON user(status, id); -- Java 中只查需要字段 String sql = "SELECT id FROM user WHERE status IS NULL";
❌ IS NOT NULL 一般不走索引（除非配合高选择性条件或覆盖索引），更推荐从设计层规避：
→ 字段设为 NOT NULL DEFAULT '' 或 0，用 = '' 或 = 0 替代 IS NULL / IS NOT NULL。
Java 层协同优化建议
动态 SQL 拼接时，优先生成
IN、BETWEEN、=，慎用!=和OR
MyBatis 的<choose>或 QueryDSL 的where().and().in(...)比手拼!=更可控。对 NULL 敏感字段，统一约定存储语义
比如用'N/A'代替NULL，或用tinyint(1)代替boolean NULL，从根本上消除IS NULL场景。开启慢查询日志 + EXPLAIN 日志透出
在 Java 日志中记录实际执行 SQL 及其EXPLAIN结果（可通过Connection.prepareStatement("EXPLAIN " + sql)获取），便于快速定位是否真走了索引。
不复杂，但容易忽略的是：索引有效性永远取决于查询写法与数据分布的共同作用，而不是“加了索引就万事大吉”。
