sql复杂查询提效关键在于逻辑分层、索引适配与结构精简：高选择性条件前置、慎用NOT/!=/LIKE’%xxx’、JOIN明确驱动表并加索引、函数移出WHERE、善用子查询或CTE预处理。
SQL复杂条件查询不是堆砌WHERE子句，而是靠逻辑分层、索引适配和结构精简来提升效率。写得“全”不如写得“准”，查得“慢”往往因为条件没对齐数据分布或索引策略。
用AND/OR时，优先按选择性排序
选择性（selectivity）指条件过滤后剩余数据占比——越小越好。高选择性条件（如id = 123、status = ‘paid’）应放在WHERE开头，让优化器尽早剪枝。
- ✅ 推荐：
WHERE user_id = 1001 AND created_at >= '2024-01-01' AND is_deleted = 0（假设user_id是主键，选择性≈1） - ❌ 避免：
WHERE is_deleted = 0 AND created_at >= '2024-01-01' AND user_id = 1001（低选择性条件前置，可能跳过索引使用）
慎用NOT、!=、LIKE ‘%xxx’——它们大概率走全表扫描
这些操作符通常无法利用B+树索引的有序性。尤其LIKE以通配符开头（如LIKE '%abc'）完全失效；NOT IN遇到NULL会返回空结果集，逻辑易错。
- 替代
NOT IN (subquery)：用NOT EXISTS更安全，且支持关联优化 - 替代
LIKE '%关键词'：考虑全文索引（mysql FULLTEXT）、倒排索引（PG trigram）或应用层预处理字段（如加前缀码） - 需要范围排除？用
BETWEEN或拆成两个/<code>>组合，比!=更可控
多表JOIN要明确驱动表，避免笛卡尔积陷阱
复杂查询常含3张以上表关联。数据库一般选结果集最小的表作为驱动表（即先查的那张）。若统计信息不准或写法干扰，可能选错，导致临时表暴增。
- 用
EXPLAIN看rows和type列：type=ALL是全表扫描，type=ref/eq_ref才健康 - 给JOIN字段加索引——不只是主键，外键列、ON条件列都应有对应索引
- 必要时用
STRAIGHT_JOIN（MySQL）或/*+ leading() */（oracle/PG）手动指定连接顺序
把计算和函数移出WHERE，改在JOIN或子查询中预处理
写WHERE YEAR(created_at) = 2024或WHERE UPPER(name) = 'TOM'，索引直接失效。日期函数、字符串函数会让字段失去可索引性。
- ✅ 改为：
WHERE created_at >= '2024-01-01' AND created_at - ✅ 改为：
WHERE name = 'tom' /* 并建LOWER(name)函数索引 */或提前存标准化字段（如name_lower） - 聚合类条件（如“订单数>5”）放到HAVING前，先用子查询或CTE算好再过滤
基本上就这些——不复杂但容易忽略。真正高效的复杂查询，80%靠前期表设计与索引规划，20%靠写SQL时多想一层“这个条件，数据库能怎么快？”