SQL查询需精简字段、明确JOIN类型、合理使用索引、注意NULL判断、优化排序分页。SELECT只取必要字段并加表别名；WHERE优先等值条件且避免索引列函数；JOIN区分ON与WHERE；ORDER BY和LIMIT须配索引，深分页改用游标。
SQL基础查询不难，但写得清晰、高效、可维护，需要掌握几个关键点。重点不是记住所有语法，而是理解逻辑顺序和常见陷阱。
SELECT语句要精简，别用 * 代替字段名
写查询时习惯性写 SELECT * 很方便，但实际会拖慢速度、增加网络传输、掩盖表结构变化风险。尤其在多表关联或大数据量场景下更明显。
- 只查真正需要的字段，比如 SELECT user_id, username, created_at
- 字段名带表别名（如 u.username），避免歧义，也方便后期维护
- 如果只是计数，直接用 SELECT COUNT(*)，不用查全行再用代码数
WHERE条件注意顺序和索引匹配
WHERE里的条件顺序不影响执行计划（优化器会重排），但你写的条件是否能走索引，直接影响性能。
- 优先使用有索引的字段做等值判断（=、IN），避免在索引列上用函数或运算，比如 WHERE YEAR(create_time) = 2024 会让索引失效
- 范围查询（>、）尽量放在等值条件之后，利于联合索引最左匹配
- NULL 判断要单独注意：IS NULL 可走索引（取决于引擎和索引类型），但 != NULL 或 NULL 永远不成立，别这么写
JOIN要明确类型，ON条件别错放WHERE
LEFT JOIN 和 INNER JOIN 的语义完全不同，写错会导致数据丢失或重复；另外，过滤条件的位置很关键。
- ON 是关联时的条件，决定哪些行参与连接；WHERE 是连接完成后的筛选
- LEFT JOIN 后想保留左表全部记录，但又在 WHERE 加了右表字段的限制（如 WHERE r.status = 'active'），就悄悄变成 INNER JOIN 了
- 建议：把关联逻辑全放 ON，业务过滤放 WHERE；实在分不清，先用子查询或 CTE 拆开写清楚
排序和分页记得加索引，LIMIT 配合 ORDER BY 才有效
ORDER BY + LIMIT 看似简单，但如果没索引，数据库得先全表排序再取前N条，非常慢。
- 对常用排序字段建索引，比如 ORDER BY created_at DESC LIMIT 10，就给 created_at 加倒序索引
- 分页深了（如 LIMIT 10000, 20）效率骤降，考虑用“游标分页”：记录上一页最大ID，下一页查 WHERE id > 12345 ORDER BY id LIMIT 20
- 避免在 ORDER BY 里用表达式或函数，同样会导致索引失效
基本上就这些。不复杂，但容易忽略。写完查一遍：字段有没有冗余？条件能不能走索引？JOIN 是不是真需要？排序有没有支撑？顺一遍，效率常能提升几倍。
