平时做数据查询的时候，很多人习惯用“!=”或者“NOT IN”这类条件来排除某些值，比如查“不是管理员的用户”会写成 WHERE role != 'admin'。这种写法看起来没问题，但性能上可能埋了坑。
负向查询到底能不能走索引？
答案是：大多数情况下，负向查询无法有效利用索引，甚至直接导致全表扫描。
拿 MySQL 来说，B+树索引适合查找明确范围或具体值，比如 =、>、IN 这类操作。而 != 或 NOT 这种否定条件，数据库引擎很难通过索引快速定位——因为它要找的是“除了这些之外的所有”，这个范围太广，索引的优势就没了。
举个例子，假设 user 表在 status 字段上有索引：
SELECT * FROM user WHERE status != 1;即便 status 有索引，这条语句大概率还是会全表扫描。因为 status 不等于 1 的记录可能占了大部分数据，MySQL 会觉得走索引再回表还不如直接扫一遍来得快。
NOT IN 更要小心
更麻烦的是 NOT IN，特别是子查询场景：
SELECT * FROM user WHERE id NOT IN (SELECT user_id FROM banned);如果 banned 表里有 NULL 值，整个查询结果就会变成空。这是 SQL 的三值逻辑问题：只要有 NULL 参与，NOT IN 判断就会失效。而且这种嵌套查询通常也无法走高效索引路径，性能雪崩。
有没有替代方案？
当然有。想避开负向查询的坑，可以换个思路：
用 LEFT JOIN + IS NULL 代替 NOT IN：
SELECT u.* FROM user u
LEFT JOIN banned b ON u.id = b.user_id
WHERE b.user_id IS NULL;这样不仅能避免 NULL 导致的逻辑错误，还能充分利用被驱动表上的索引，执行效率高得多。
如果是简单的状态排除，也可以考虑正向列举：
SELECT * FROM user WHERE status IN (0, 2, 3);虽然写起来啰嗦点，但如果可选值不多，反而更容易命中索引。
特殊情况也有例外
并不是所有负向查询都完全不能用索引。比如数据分布极度倾斜时，像“删除标记为 0 的占 99%”，那么查 flag != 0 其实只返回极少记录，这时候优化器可能会选择走索引。但这属于特例，不能依赖。
另外，一些数据库支持函数索引或位图索引，也能在特定场景下缓解问题。但主流 MySQL、PostgreSQL 在普通 B+树索引下，对负向操作依然不友好。
实际开发中，与其赌优化器聪明，不如从设计上规避。比如把“非某类”转换成“属于其他明确类别”，或者加一个冗余字段专门标记是否需要包含，让查询变正向。
线上系统一旦出现慢查询，很多就是藏在某个“!=”后面的陷阱。别小看这一笔一划，它可能正在拖垮你的接口响应速度。