不等于查询慢是因为b+树索引无法高效处理!=或，优化器常退化为全表扫描；可通过union all改写为多个等值查询，或更优地添加冗余布尔字段（如is_final_status）并建索引。
不等于查询为什么慢？索引基本失效
MySQL 对 != 或 条件几乎无法使用 B+ 树索引的范围扫描能力，优化器通常会退化为全表扫描或全索引扫描。即使字段上有索引，只要写成 WHERE status != 'done'，InnoDB 很可能放弃走索引——因为“不等于”天然对应大量离散值，无法利用索引的有序性做高效跳转。
常见错误现象包括：
- 执行计划中
type显示为ALL或index -
rows值接近表总行数 -
Extra出现Using where但没Using index
这不是配置问题，是 B+ 树索引结构决定的限制。
Union 改写的核心逻辑：把“排除”转成“明确包含”
本质是手动拆解补集：将 WHERE col != 'X' 拆成多个带等值条件的子查询，再用 UNION ALL 合并。前提是你知道该列所有可能的取值（或至少高频/有限的取值）。
适用场景：
- 字段为枚举型（如状态字段只有
'pending'、'processing'、'done'） - 表数据分布倾斜，少数几个值占绝大多数
- 能接受 SQL 变长（新增状态需改 SQL）
例如原查询：
SELECT * FROM orders WHERE status != 'done';
可改写为：
SELECT * FROM orders WHERE status = 'pending' UNION ALL SELECT * FROM orders WHERE status = 'processing' UNION ALL SELECT * FROM orders WHERE status = 'failed';
注意必须用 UNION ALL（而非 UNION），避免去重开销；每个子句都能命中 status 索引的等值查找。
改写后仍要检查的三个关键点
- 索引是否覆盖所有
WHERE 子句中的字段：如果 status 有索引，但子查询里还带 AND created_at > '2024-01-01'，就得建联合索引，比如 (status, created_at)
-
UNION 结果集字段顺序和类型必须严格一致，否则报错 ERROR 1222 (21000): The used SELECT statements have a different number of columns
- 如果原始查询含
ORDER BY 或 LIMIT，不能直接加在外层——MySQL 5.7 不支持 UNION 外层直接 LIMIT，得包一层子查询：SELECT * FROM (
SELECT id, status FROM orders WHERE status = 'pending'
UNION ALL
SELECT id, status FROM orders WHERE status = 'processing'
) t ORDER BY id LIMIT 10;
比 Union 更稳的替代方案：加冗余标记字段
WHERE 子句中的字段：如果 status 有索引，但子查询里还带 AND created_at > '2024-01-01'，就得建联合索引，比如 (status, created_at)
UNION 结果集字段顺序和类型必须严格一致，否则报错 ERROR 1222 (21000): The used SELECT statements have a different number of columns
ORDER BY 或 LIMIT，不能直接加在外层——MySQL 5.7 不支持 UNION 外层直接 LIMIT，得包一层子查询：SELECT * FROM ( SELECT id, status FROM orders WHERE status = 'pending' UNION ALL SELECT id, status FROM orders WHERE status = 'processing' ) t ORDER BY id LIMIT 10;
Union 改写维护成本高，一旦状态值增加就得改 SQL。更可持续的做法是在业务写入时，同步维护一个布尔字段，比如 is_final_status：
ALTER TABLE orders ADD COLUMN is_final_status TINYINT(1) DEFAULT 0; -- 写入时根据 status 设置：'done' → 1，其余 → 0 CREATE INDEX idx_is_final ON orders(is_final_status);
之后查“非完成单”就变成：
SELECT * FROM orders WHERE is_final_status = 0;
这个查询能稳定走索引，且不受枚举值膨胀影响。代价是写入路径多一次计算，但读多写少场景下非常值得。
Union 是应急手段，加标记字段才是面向长期演进的设计。别在 SQL 层硬扛语义转换。
