MySQL用LIMIT OFFSET查前10行越来越慢是因为OFFSET强制扫描跳过所有前面的行，即使只取第1行，OFFSET 1000000也要定位到第1000001行才开始取，数据量大时比全表扫描还慢。
MySQL用LIMIT OFFSET查前10行为什么越来越慢
因为OFFSET会强制数据库扫描并跳过前面所有行，哪怕你只要第1行，OFFSET 1000000也会让MySQL定位到第1000001行才开始取——中间全白算。数据量一上百万，LIMIT 10 OFFSET 1000000可能比全表扫描还慢。
实操建议：
- 能不用
OFFSET就不用，尤其在分页深度超过几百页时 - 如果只是要“前N行”，直接用
LIMIT N，不加OFFSET——这是唯一真正高效的写法 - 如果业务真需要翻页（比如后台列表），改用基于游标的分页：用上一页最后一条的
id或created_at做条件，例如WHERE id > 12345 ORDER BY id LIMIT 10 - 确保排序字段有索引，否则
ORDER BY本身就会触发文件排序，再加OFFSET等于雪上加霜
PostgreSQL里用FETCH FIRST比LIMIT更规范吗
语法上更标准（SQL:2008），但性能和LIMIT完全一致，底层都走同样执行计划。区别只在语义清晰度和兼容性——FETCH FIRST 10 ROWS ONLY明确表达“只取前10行”，而LIMIT 10是PostgreSQL/MySQL的扩展写法。
实操建议：
- 新项目或跨数据库场景，优先用
FETCH FIRST 10 ROWS ONLY，避免LIMIT在SQL Server、Oracle里不识别 - 不要以为它能绕过
OFFSET的性能问题——OFFSET 1000000 FETCH FIRST 10 ROWS ONLY照样慢 - 如果用
ORDER BY+FETCH FIRST，必须确认排序列已建索引，否则Plan里会出现Sort节点，且Rows Removed by Filter高得离谱
SQL Server中TOP N和OFFSET FETCH的取舍
TOP N是SQL Server原生语法，快且稳定；OFFSET FETCH是SQL:2012引入的通用分页方案，但实现不如TOP轻量。两者在取“前N行”时结果一致，但执行计划不同。
实操建议：
- 只要取前几行（比如首页列表），无条件用
SELECT TOP 10 * FROM table ORDER BY id，它不经过排序缓冲区重排，也不触发OFFSET扫描逻辑 - 避免写
OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY——多此一举，还多一次解析开销 - 如果后续要支持跳转到任意页（如用户手动输页码），才考虑
OFFSET FETCH，但必须配合覆盖索引，否则Key Lookup会拖垮性能 - 注意
TOP不加ORDER BY是未定义行为，返回顺序不可靠，生产环境必须显式写ORDER BY
大表导出前100行调试时，别碰WHERE子句里的函数
比如WHERE DATE(created_at) = '2024-01-01'会让索引失效，即使你只想要前100行，MySQL也得先对全部created_at计算DATE()，再过滤，最后LIMIT——等于全表函数计算。
实操建议：
- 调试提取前N行时，先确认
WHERE条件是否走索引：用EXPLAIN看key列是否非NULL，rows是否接近你要的N值 - 把函数移到右边：用
WHERE created_at >= '2024-01-01' AND created_at 替代<code>DATE(created_at) - 如果表没主键或排序字段，
LIMIT行为不稳定，不同执行可能返回不同行——加ORDER BY哪怕只是ORDER BY id，确保可复现
最常被忽略的一点：很多人以为“我只是取前10行，数据量小，怎么写都快”，但数据库优化器不会因为你只想要10行就跳过全表扫描逻辑——它得先确定哪10行满足条件，而这一步的代价，藏在WHERE和ORDER BY里，不在LIMIT上。
