典型“SQL引发的内存雪崩”是因全表扫描返回海量数据导致堆内存溢出，需通过堆dump、慢SQL日志和EXPLAIN分层验证，并以LIMIT分页和索引优化根治。
Java应用中因SQL语句未走索引、触发全表扫描，导致数据库返回海量数据，进而使JVM堆内存被大量ResultSet或实体对象占满，最终引发java.lang.OutOfMemoryError: Java heap space——这是典型的“SQL引发的内存雪崩”，不是代码本身内存泄漏，而是数据量失控所致。
查清是不是真因全表扫描导致OOM
不能仅凭OOM就断定是SQL问题，需分层验证：
- 检查JVM堆dump（用jmap/jvisualvm）：确认堆中占比最高的对象是否为
java.util.ArrayList、com.mysql.cj.jdbc.result.ResultSetImpl或你项目中的实体类（如User、Order），数量达数十万甚至百万级； - 查看慢SQL日志（如MySQL的slow_query_log）：找执行时间长、Rows_examined远大于Rows_sent的语句（例如
Rows_examined=500000, Rows_sent=1000）； - 在数据库中用
EXPLAIN分析该SQL：重点看type是否为ALL（全表扫描）、key是否为NULL、rows预估是否过大。
快速止损：加LIMIT + 分页改造
线上已OOM时，优先控制单次查询数据量，避免服务直接不可用：
- 对非必要全量导出/报表类接口，强制加上
LIMIT 1000（或业务可接受的上限），并明确返回“数据量超限，请按条件筛选”； - 将一次性查10万条的逻辑，改为游标分页（
WHERE id > ? ORDER BY id LIMIT 1000）或基于时间范围分段（如按天/月查）； - MyBatis中避免
<select> SELECT * FROM table</select>裸查，必须带WHERE和分页参数（RowBounds或PageHelper）。
根治：让SQL真正走索引
不只建索引，更要让索引被用上：
立即学习“Java免费学习笔记（深入）”；
- WHERE条件字段必须有索引，且符合最左前缀原则（如索引
(status, create_time)，则WHERE status = ? AND create_time > ?能命中，但WHERE create_time > ?不能）； - 避免在索引字段上做函数操作：
WHERE DATE(create_time) = '2024-01-01'会失效，应改写为WHERE create_time >= '2024-01-01' AND create_time ； - 注意隐式类型转换：如数据库字段是
VARCHAR，Java传入Long类型参数，可能导致索引失效（MySQL会自动转成字符串再比对）； - 定期用
ANALYZE TABLE更新统计信息，避免优化器误判走错执行计划。
预防：从开发流程卡住高危SQL
靠人审SQL容易漏，要用机制兜底：
- 接入SQL审核工具（如阿里Druid的
stat监控、网易DMS、或自研拦截器），对无WHERE、无LIMIT、扫描行数预估＞1万的SQL打告警甚至拒绝执行； - 单元测试/集成测试中加入数据量断言：比如“查询订单列表接口，返回结果size ≤ 100”；
- 上线前要求提供
EXPLAIN结果截图，并由DBA确认执行计划合理。
这类问题本质是数据访问层与数据库协同失衡，修复关键不在调大JVM内存，而在让SQL变“轻”——少查、快查、精准查。不复杂但容易忽略。
