数据库踩坑实录：这行 SQL 让服务器直接宕机

21 Mar 2026 — 2 min read

全表扫描未优化查询 当执行没有合适索引的查询时，数据库可能被迫扫描整个表。例如：

SELECT * FROM large_table WHERE unindexed_column = 'value';

这种查询在数据量大的表中会消耗大量 I/O 和 CPU 资源。

缺失索引的 JOIN 操作 多表连接时如果关联字段没有索引：

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;

会产生两表行数乘积的结果集。

递归查询失控 未设置终止条件的递归 CTE：

WITH RECURSIVE infinite_loop AS ( SELECT 1 AS n UNION ALL SELECT n+1 FROM infinite_loop ) SELECT * FROM infinite_loop;

内存设置不当 过小的排序缓冲区：

SET sort_buffer_size = 128*1024;

处理大排序时会导致磁盘临时文件。

连接池耗尽 未限制最大连接数时，大量并发连接：

-- 每个应用线程都创建独立连接

监控长时间运行的查询，为常用查询条件添加索引。大规模数据操作应分批进行，测试环境验证查询执行计划后再上线。合理配置数据库内存参数，设置查询超时和连接数限制。定期维护统计信息和索引碎片整理。

Read more