MySQL 的
SELECT语句不是“用不用”的问题，而是“怎么写才不踩坑、不出错、不慢、不漏数据”的问题。绝大多数查询错误和性能问题，都出在基础语法理解偏差或忽略隐含行为上。
WHERE 条件里 NULL 不能用 = 判断
这是新手最常栽跟头的地方：写
WHERE status = NULL永远查不到任何行，因为 SQL 中
NULL参与的任何等值比较（
=、
!=、）结果都是
UNKNOWN，不满足
WHERE的真值要求。 正确写法是
WHERE status IS NULL或
WHERE status IS NOT NULL如果字段可能为
NULL，又想统一处理（比如当默认值），可用
COALESCE(status, 'unknown')或
IFNULL(status, 'unknown')注意：索引列上使用
IS NULL通常能走索引，但
IS NOT NULL在某些旧版本 MySQL 中可能触发全表扫描
ORDER BY 后没加 LIMIT 时的隐式风险
开发阶段随手写
SELECT * FROM orders ORDER BY created_at DESC看着没问题，上线后可能拖垮数据库——尤其当表有百万行且
created_at没索引时，MySQL 得排序全部数据再返回全部结果。 除非明确需要全部结果，否则必须加
LIMIT；分页场景优先用游标（
WHERE created_at ），而非 <code>OFFSET
ORDER BY字段必须和
WHERE条件中高选择性字段组合建联合索引，否则排序会走 filesort 字符串字段排序要注意字符集和校对规则（如
utf8mb4_0900_as_cs区分大小写），可能影响结果顺序
JOIN 时 ON 和 WHERE 的执行时机差异
左连接中，把过滤条件写在
ON还是
WHERE会导致结果完全不同。例如：
SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'，和把
o.status = 'paid'移到
WHERE后，前者保留所有用户（没支付订单的
o.*为
NULL），后者实际变成内连接（
NULL被
WHERE过滤掉）。
ON是连接过程中决定“哪些右表行能匹配进来”，
WHERE是连接完成后对整行结果的最终筛选 多表
LEFT JOIN时，后续
JOIN的
ON条件只能引用左侧已存在的表，不能跨跳引用更早的表（MySQL 5.7+ 支持部分放宽，但语义易混淆） 用
EXPLAIN看
type和
Extra字段，确认是否用了索引、是否产生临时表或 filesort
GROUP BY 严格模式下非聚合字段报错
MySQL 5.7 默认开启
sql_mode=ONLY_FULL_GROUP_BY，此时
SELECT id, name, COUNT(*) FROM users GROUP BY city会直接报错，因为
id和
name不在
GROUP BY列中，也不在聚合函数里。 解决方式只有三种：补全
GROUP BY id, name, city；或只选
city和聚合字段；或用
ANY_VALUE(id)显式声明接受任意值（需确认业务逻辑允许） 不要轻易关掉
ONLY_FULL_GROUP_BY，它暴露的是查询逻辑缺陷，而不是配置问题
GROUP BY字段如果有函数包装（如
DATE(created_at)），记得给该表达式建函数索引（MySQL 8.0+）或冗余生成列 + 索引
真正难的从来不是写出能跑的
SELECT，而是写出在数据量增长、并发升高、字段值分布变化后依然稳定、可预期、可维护的查询。每个
WHERE条件、每处
JOIN、每次
GROUP BY，背后都有执行计划和索引策略在起作用——别让语法正确掩盖了语义风险。
