应使用游标分页替代OFFSET分页：第一页查前10条，后续页通过上一页最后记录的排序字段值（如created_at）加WHERE条件查询，避免全表扫描和跳过大量数据。
MySQL 中 ORDER BY 配合 LIMIT 的分页查询，看似简单，但在数据量大时极易成为性能瓶颈。根本原因在于：数据库可能需要先对全表或大量数据排序，再取前 N 条——即使你只要第 100 页的 10 条记录。
避免“深分页”：用游标分页（Cursor-based Pagination）替代 OFFSET
传统写法 ORDER BY created_at DESC LIMIT 10000, 10 会让 MySQL 扫描并跳过前 10000 行，效率随偏移量线性下降。更优方式是记住上一页最后一条记录的排序字段值（如时间戳或主键），下一页直接从该值之后查：
- 第一页：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 - 第二页（假设第一页最后一条
created_at = '2024-05-01 10:20:30'）：SELECT * FROM orders WHERE created_at
这个条件能有效利用索引，避免全排序和跳行，响应时间稳定。
确保排序字段有高效索引
仅在 ORDER BY 字段建单列索引往往不够。推荐使用**覆盖索引 + 复合索引**策略：
- 如果查询是
SELECT id, name, status FROM users ORDER BY status, created_at DESC LIMIT 20，应建复合索引：INDEX(status, created_at)（注意顺序：等值条件字段在前，排序字段在后；多列排序需方向一致） - 若还包含
WHERE条件（如WHERE status = 'active'），该索引仍可复用，且支持索引下推（ICP） - 避免在排序字段上使用函数或表达式（如
ORDER BY UPPER(name)），会导致索引失效
减少排序数据量：提前过滤，避免 SELECT *
不必要的字段会增加 I/O 和内存排序开销，尤其当排序缓存（sort_buffer_size）不足时会触发磁盘临时文件（Using filesort）。
- 只查真正需要的字段，避免
SELECT * - 用
WHERE尽早缩小结果集范围（例如加时间范围、状态过滤），再排序分页 - 检查执行计划：
EXPLAIN中出现Using filesort或Using temporary是明显信号，需优化索引或逻辑
合理配置排序相关参数（仅限必要调优）
默认参数适合通用场景，但面对高频分页查询可微调：
-
sort_buffer_size：每个连接独享，不宜设过大（如超过 4MB 可能浪费内存），建议按并发数与平均排序量估算 -
read_rnd_buffer_size：影响排序后回表读取的随机 I/O 效率，可略高于sort_buffer_size - 不建议盲目调高；优先靠索引和逻辑优化解决，参数只是辅助
不复杂但容易忽略：排序分页慢，90% 情况不是 MySQL 不行，而是没让索引真正生效，或者还在用 OFFSET 跳着翻页。
