ORDER BY created_at DESC LIMIT 1 不保证取最新订单，因时间重复会导致结果不稳定；须联合唯一字段如id排序，或提升时间精度至微秒并重建索引。
ORDER BY 后 LIMIT 1 不等于“取最新订单”
很多同学写 SELECT * FROM orders ORDER BY created_at DESC LIMIT 1，以为一定能拿到最新下单的那条——但只要 created_at 有重复（比如批量导入、毫秒级并发、数据库时钟未同步），结果就不稳定。MySQL 8.0+ 虽然默认按插入顺序补位，但不保证，PostgreSQL 更是明确不保证。
实操建议：
- 业务上真正需要“最新”，必须加唯一性兜底：比如联合
id（自增或 UUID）：ORDER BY created_at DESC, id DESC LIMIT 1 - 如果用的是
timestamp类型且精度只有秒，直接改字段为TIMESTAMP(6)（微秒）再重建索引 - 避免在应用层靠多次查询“猜”最新：比如先查 max(created_at)，再查等于该时间的记录——这会引发 N+1 和幻读
LEFT JOIN 多张订单关联表时丢失主表数据
写 SELECT o.*, u.name FROM orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN order_items i ON o.id = i.order_id，发现某些订单突然没了——问题出在第二个 LEFT JOIN 的 ON 条件没过滤掉空值，但后续 WHERE 或隐式条件（比如 i.status = 'shipped'）把整行干掉了。
实操建议：
-
LEFT JOIN后所有对右表字段的过滤，必须写进ON子句，不能放WHERE；否则等效于INNER JOIN - 想查“订单 + 用户名 + 已发货的商品数”，别写
WHERE i.status = 'shipped'，而要写LEFT JOIN order_items i ON o.id = i.order_id AND i.status = 'shipped' - 不确定是否有多行匹配时，用
COUNT(i.id)而不是COUNT(*)，避免重复计数
UPDATE orders SET status = 'paid' WHERE id IN (...) 批量更新卡死
线上执行 UPDATE orders SET status = 'paid' WHERE id IN (1,2,3,...,5000)，发现锁住整个表、慢得离谱，甚至触发死锁告警——这不是 SQL 写错了，是 MySQL 对大 IN 列表的优化器策略失效，容易走全表扫描 + 逐行加锁。
实操建议：
- IN 列表超过 500 个值，立刻拆成多个批次，每批 200–300 个：
WHERE id IN (1..200)、WHERE id IN (201..400) - 确保
id字段有主键或唯一索引，否则即使小批量也会全表扫 - 别用临时表或子查询替代 IN（如
WHERE id IN (SELECT id FROM tmp_ids)），MySQL 5.7 对这类写法优化极差，可能比 IN 还慢 10 倍
GROUP BY 后 COUNT(DISTINCT user_id) 和 SUM(amount) 对不上
统计每个销售员的订单数和总金额：SELECT seller_id, COUNT(DISTINCT user_id), SUM(amount) FROM orders GROUP BY seller_id，结果发现某销售员订单数是 10，但用户去重后只有 3 个——这本身没问题；但如果你本意是“每个用户只算一次购买”，却忘了 COUNT(DISTINCT ...) 和 SUM(...) 是在不同粒度上聚合的。
实操建议：
- 明确业务语义：是“用户维度去重后汇总”，还是“订单维度汇总后再人工去重”？前者必须用窗口函数或子查询先去重
- 别指望
COUNT(DISTINCT)在大数据量下快：MySQL 5.7 默认用临时表 + 文件排序，可考虑升级到 8.0+ 并开启optimizer_switch='derived_merge=on' - 测试时用
EXPLAIN FORMAT=TREE看实际执行计划，确认有没有用到Using temporary; Using filesort
订单状态流转、时间精度、JOIN 语义、批量操作锁粒度——这些地方看着像基础语法，但线上一出问题就是雪崩。最常被跳过的其实是字段类型定义和索引覆盖，比如 status 用 VARCHAR(20) 而不是 ENUM 或 TINYINT，查起来慢三倍，还占更多 buffer pool。
