TP5.1的paginate()在大数据量下变慢，因其默认执行SELECT * FROM table LIMIT offset, size，MySQL需真实扫描并丢弃前offset+size行，导致IO与CPU双重浪费；应改用子查询+JOIN或游标分页优化。
为什么 TP5.1 的 paginate() 在大数据量下会变慢
TP5.1 的 paginate() 默认生成的是 SELECT * FROM table LIMIT offset, size 这类 SQL。当 offset 超过 10 万，哪怕只查 10 条，MySQL 也得扫描并丢弃前 offset + size 行——不是跳过去，是真读、真排序、真扔掉。数据量越大，这个“读-扔”过程越吃 CPU 和磁盘 IO。
手动改写分页 SQL：用子查询 + JOIN 替换 paginate()
TP5.1 不支持直接在 paginate() 里注入子查询逻辑，必须绕开它，手写原生 SQL 或用 Db::query() 执行优化语句。核心是两步：先捞 ID，再关联查详情。
- 确保你有合适的复合索引，比如查询条件是
status = 1、按created_at DESC排序，那索引必须是INDEX(status, created_at, id)（id放最后，让子查询能覆盖） - 子查询里只能写
SELECT id，不能加*或其他字段，否则 MySQL 会放弃覆盖索引 - JOIN 条件必须是
ON t1.id = t2.id这种等值连接；用IN或范围条件（如id > ?）可能触发全表扫描 - 示例（查状态为 1 的订单，从第 100 万条开始取 20 条）：
SELECT t1.* FROM orders t1
INNER JOIN (
SELECT id FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 1000000, 20
) t2 ON t1.id = t2.id;游标分页更适合 TP5.1 的高并发场景
如果你的业务允许“下一页/上一页”而非“跳转任意页”，游标分页比 offset 分页稳定得多。TP5.1 里没法用 paginate() 直接支持，但你可以用 where() + limit() 手动拼。
- 排序字段必须唯一且有索引，推荐组合
(created_at, id)，避免时间戳重复导致漏数据 - 前端需传上一页末尾的
cursor值（比如"2025-06-01 12:00:00,123456"），后端拆解后用于WHERE - 典型写法（假设游标是
created_at和id）：
SELECT * FROM orders
WHERE (created_at, id) < ('2025-06-01 12:00:00', 123456)
AND status = 1
ORDER BY created_at DESC, id DESC
LIMIT 20;注意：这里用的是行比较语法（MySQL 8.0+ 支持），TP5.1 连接的 MySQL 版本低于 8.0 时，得拆成两个条件：created_at 。
TP5.1 里容易被忽略的坑
很多人写了优化 SQL，但一跑还是慢——问题常出在索引或 ORM 干预上。
-
paginate()内部会自动加COUNT(*)查询总数，这个 COUNT 如果没走覆盖索引，本身就会扫全表。建议业务上禁用总数显示（->paginate(20, false)），或单独建INDEX(status, created_at)加速 COUNT - TP5.1 的
field()方法如果写成field('id, name, email')，而你又没建对应联合索引，子查询仍可能回表 - 使用
Db::name('orders')->where(...)->limit(...)->select()时，TP5.1 不会自动帮你加 JOIN 逻辑，必须自己写完整 SQL - 缓存层（如 Redis）别缓存带 offset 的分页结果，因为数据变动后极易失效或错乱；游标分页的缓存更安全，key 可基于游标值哈希
