生产环境常见的 SQL 性能陷阱
作为老后端，见过太多因为一条 SQL 把库搞挂的情况。很多时候问题不出在代码逻辑上，而是藏在查询语句的细节里。下面复盘几个典型的'杀手级'写法。
全表扫描：索引缺失的代价
当执行没有合适索引的查询时，数据库可能被迫扫描整个表。比如这种写法：
SELECT * FROM large_table WHERE unindexed_column = 'value';
在数据量大的表中，这种查询会消耗大量 I/O 和 CPU 资源，直接拖慢甚至阻塞其他业务。
关联查询的隐患
多表连接时如果关联字段没有索引，后果更严重。例如：
SELECT * FROM table_a JOIN table_b ON table_a.unindexed_id = table_b.unindexed_id;
这会导致数据库执行昂贵的嵌套循环操作，随着数据量增长，响应时间呈指数级上升。
高资源消耗操作
大型事务处理 单事务中包含过多操作是禁忌。像这样的批量写入：
BEGIN;
INSERT INTO log_table SELECT * FROM huge_source_table;
UPDATE statistics SET count = count + 1000000;
COMMIT;
会长时间占用锁资源并填满日志文件，一旦超时或回滚，恢复成本极高。
不当的批量操作 没有分批次的大批量删除同样危险：
DELETE FROM session_table WHERE expire_time < NOW();
可能引发锁等待和事务日志膨胀，导致主从延迟甚至服务不可用。
查询设计缺陷
笛卡尔积查询 忘记指定连接条件是最容易踩的坑：
SELECT * FROM users, orders;
会产生两表行数乘积的结果集，瞬间撑爆内存。
