多条件查询本质是集合运算：AND为交集、OR为并集、NOT为补集；优先级上AND高于OR，需显式加括号；IN、BETWEEN、LIKE均定义特定值集合；动态条件应参数化构造有效集合表达式。
多条件查询本质是集合运算
MySQL 的 WHERE 多条件查询，不是“逐行判断后拼起来”，而是对整张表做一次**逻辑集合裁剪**：把原始数据集看作全集 U，每个条件（如 age > 25）对应一个子集，AND 是交集 ∩，OR 是并集 ∪，NOT 是补集 ¬。
-
WHERE dept = '技术部' AND salary >= 12000→ 技术部集合 ∩ 高薪集合 -
WHERE dept = '技术部' OR gender = '男'→ 技术部集合 ∪ 男性集合（含非技术部的男员工） WHERE NOT (age → 全集减去未成年集合，等价于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，先想清楚你要切的是哪几刀。
