LIMIT和OFFSET组合本身不会直接导致OOM，但OFFSET过大时MySQL需扫描并丢弃大量行，触发文件排序、磁盘临时表及JVM堆溢出，最终引发OOM或连接被kill。
直接说结论：LIMIT 和 OFFSET 组合本身不会导致 OOM，但不当使用会引发内存暴涨、查询卡死甚至连接被 kill——根本原因是 MySQL 在执行时必须扫描并丢弃前 OFFSET 行，这些行仍要参与排序、回表、临时表构建等操作，最终把内存/磁盘撑爆。
为什么 OFFSET 大了会 OOM？
MySQL 不是“跳到第 N 行直接读”，而是从头扫描，逐行判断是否该跳过。当 OFFSET = 1000000 时：
- 即使只返回 20 行，也要先读取至少 100 万 + 20 行（取决于索引覆盖程度）
- 若
ORDER BY字段无索引或无法利用索引，会触发Using filesort，生成大临时文件 - 若结果集字段多、有
TEXT/BLOB，每行内存占用高，sort_buffer_size和tmp_table_size很快耗尽 - MyBatis 等 ORM 默认将整页结果加载进 JVM List，
OFFSET过大会让 Java 堆直线上升，触发 Full GC 或OutOfMemoryError
怎么写才不容易 OOM？
核心原则：控制 OFFSET 上限 + 确保能走索引 + 减少单次数据体积
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 后端强制校验：
if (offset > 10000) { throw new IllegalArgumentException("不支持超过1000页"); } -
ORDER BY必须命中索引最左前缀，且字段顺序与索引定义严格一致（例如索引是(status, created_at, id)，就不能只ORDER BY created_at） - 避免
SELECT *，只查必要字段；尤其避开TEXT、JSON类型列，否则回表开销翻倍 - 用
EXPLAIN确认type是range或ref，且Extra中没有Using temporary或Using filesort
什么时候该彻底放弃 OFFSET？
不是所有分页都适合 LIMIT/OFFSET，尤其以下场景必须换方案：
- 用户滚动浏览 Feed 流（如朋友圈、订单列表）：改用游标分页，传
last_id=1234567，查询WHERE id > 1234567 ORDER BY id ASC LIMIT 20 - 数据实时写入频繁（每秒数百 INSERT/UPDATE）：
OFFSET分页结果会漏行或重复，游标 + 单调递增字段（id或created_at + id）更可靠 - 需要跳转任意页码（如搜索后输入“第137页”）：可接受，但必须限制最大
OFFSET，同时前端禁用超页数输入框 - 表无主键或唯一索引：加自增
row_id列，或用SELECT ... INTO OUTFILE+ 分块处理，别硬扛
最容易被忽略的一点：OFFSET 的“慢”和“OOM”不是线性增长，而是拐点式爆发——从 10 万到 100 万，可能只是响应时间从 200ms 涨到 3s；但从 100 万到 500 万，MySQL 可能直接因 tmp_table_size 不足 fallback 到磁盘临时表，再叠加并发，OOM 就在下一秒。
