SQL查询变慢主因是执行顺序不清和优化点忽略：WHERE先于SELECT执行，避免在SELECT中计算；JOIN应小表驱动大表并确保字段索引与类型一致；ORDER BY和LIMIT需配合复合索引；COUNT(*)优于COUNT(字段)，且应善用索引覆盖。
SQL查询变慢，往往不是因为语句写错了，而是执行顺序没理清、关键优化点被忽略。理解SQL真正怎么执行，比背优化技巧更重要。
WHERE先于SELECT执行，别在SELECT里做计算
很多人习惯在SELECT中写复杂表达式或函数（比如UPPER(name)、DATE(created_at)），以为只是“展示时处理”。但数据库实际会在每行数据上先算完这些，再判断是否满足WHERE条件——相当于多做了大量无效计算。
- 把过滤逻辑尽量前移到WHERE里，比如用
created_at >= '2024-01-01'代替DATE(created_at) = '2024-01-01' - 避免对索引字段使用函数或运算，否则索引失效（如
WHERE id + 1 = 100无法走id索引） - 需要大小写不敏感匹配时，优先建函数索引（如PostgreSQL的
CREATE INDEX idx_name_lower ON users ((LOWER(name)))），而不是每次查都写LOWER(name) = 'alice'
JOIN顺序影响中间结果集大小，小表驱动大表仍是有效原则
虽然现代优化器会重排JOIN顺序，但显式控制仍有必要，尤其在嵌套查询或统计类场景。如果LEFT JOIN一个超大日志表，又没加有效过滤条件，中间结果可能爆炸式膨胀。
- 确保JOIN字段有索引，且类型严格一致（如INT vs VARCHAR会导致隐式转换，索引失效）
- 在子查询或WITH中预先过滤大表，再JOIN，比直接JOIN后WHERE更高效
- 用
EXPLAIN看实际驱动表和行数预估，关注rows列是否远大于预期
ORDER BY和LIMIT要配合索引，避免Using filesort
没有合适索引时，ORDER BY会触发临时文件排序（Using filesort），数据量一上去就明显卡顿。LIMIT看似只取几条，但如果排序发生在全表扫描之后，代价依然很高。
- 复合索引需匹配ORDER BY字段顺序和方向（如
ORDER BY status, created_at DESC对应索引(status, created_at DESC)） - 如果只按单字段排序+LIMIT，该字段单独建索引通常就够用
- 避免
ORDER BY RAND()，它强制全表扫描；随机取样可用主键范围估算或应用层分页采样
COUNT(*)、COUNT(字段)差异大，别默认用COUNT(*)
COUNT(*)统计行数，多数引擎有优化（如InnoDB不扫数据只查元数据）；但COUNT(字段)必须检查该字段是否为NULL，会实实在在读取字段值。
- 统计总行数且无需精确实时，可考虑缓存或近似值（如
SHOW TABLE STATUS里的Rows） - 统计非空数量时，确保该字段有NOT NULL约束，能减少NULL判断开销
- 带WHERE的COUNT，注意是否能命中索引覆盖（即索引包含所有WHERE和COUNT涉及字段）
不复杂但容易忽略。查得慢，先看EXPLAIN输出，再对照执行顺序逐项核对：WHERE有没有走索引、JOIN有没有放大结果、ORDER BY有没有触发排序、COUNT是不是读了不该读的数据。
