多条件查询本质是集合运算
MySQL 的
WHERE多条件查询，不是“逐行判断后拼起来”，而是对整张表做一次**逻辑集合裁剪**：把原始数据集看作全集
U，每个条件（如
age > 25）对应一个子集，
AND是交集 ∩，
OR是并集 ∪，
NOT是补集 ¬。
WHERE dept = '技术部' AND salary >= 12000→ 技术部集合 ∩ 高薪集合
WHERE dept = '技术部' OR gender = '男'→ 技术部集合 ∪ 男性集合（含非技术部的男员工）
WHERE NOT (age → 全集减去未成年集合，等价于 <code>age >= 18
这种视角能立刻解释很多“反直觉”现象：比如
OR条件常导致索引失效——因为 MySQL 无法用单个 B+ 树同时高效定位两个不重叠的子集边界，往往退化为扫描多个索引再合并（Index Merge），甚至全表扫。
AND 和 OR 的优先级陷阱
MySQL 中
AND优先级高于
OR，但人脑容易按自然语言顺序读，误以为
A OR B AND C等价于
(A OR B) AND C，实际是
A OR (B AND C)。
SELECT * FROM users WHERE city = '北京' OR age > 25 AND gender = '女';
这条语句查的是：所有北京用户 + 所有又大于25岁又为女性的非北京用户，不是“北京用户或25岁以上女性”。
永远显式加括号，哪怕你觉得“没必要”：WHERE (city = '北京') OR (age > 25 AND gender = '女')用
EXPLAIN看执行计划，确认是否真的命中了你预期的索引 如果条件组合频繁变动，宁可拆成
UNION ALL，也别靠括号硬扛复杂逻辑
IN、BETWEEN、LIKE 本质也是集合定义
IN不是语法糖，它明确声明一个离散值集合；
BETWEEN是闭区间连续集合；
LIKE '%关键词%'是模糊字符串集合——它们和
=一样，都在定义“满足条件的行属于哪个子集”。
status IN ('pending', 'processing') ≡ status 属于 {pending, processing} 集合
created_at BETWEEN '2025-01-01' AND '2025-12-31'≡ created_at 属于时间线上的一个连续段
name LIKE '%tech%'≡ name 属于所有包含 tech 的字符串构成的（无限）集合
注意：
LIKE前导通配符（
'%abc'）会让索引完全失效；
IN列表过长（如上千项）可能触发优化器放弃使用索引；
BETWEEN对 datetime 字段要小心时区和秒级精度截断。
动态条件 ≠ 拼 SQL，而是构造有效集合表达式
用户搜索页常有“价格区间、品类、品牌、排序”等多个可选条件，后端不该写一堆
if/else拼 SQL 字符串——那等于手动维护几十种集合组合，极易出错且无法复用索引。 推荐用参数化预处理：
WHERE (:min_price IS NULL OR price >= :min_price) AND (:brand IS NULL OR brand = :brand)避免
IF('{0}' = '', price, '{0}') 这类模板技巧——它让 price = price成为恒真条件，但优化器未必能识别剔除，反而干扰执行计划 对高并发场景，可预先建好覆盖索引：
INDEX idx_search (status, created_at, price)，让多数组合条件能走索引范围扫描
真正难的从来不是写出能跑的 SQL，而是让每个多条件组合都落在数据库能高效计算的集合代数路径上——索引、统计信息、查询重写，全是为这件事服务的。别只盯着 WHERE 里写了几个 AND，先想清楚你要切的是哪几刀。
