ThinkPHP的paginate()在分库分表下不可用，因其依赖单库COUNT(*)+LIMIT offset，无法聚合分片总数、导致数据错乱；应改用游标分页或手动归并。
分库分表后，直接用 paginate() 会查错、慢到超时、甚至返回重复或缺失数据——这不是 ThinkPHP 的 bug，而是它压根没设计去处理分布式分页。框架的 paginate() 默认走单库 COUNT(*) + LIMIT offset, size，一进分库分表环境就失效。
ThinkPHP 的 paginate() 在分库分表下为什么不能直接用
框架的分页逻辑依赖两个关键动作：先执行一条 COUNT 获取总数，再执行带 LIMIT 的主查询。但在分库分表场景下：
-
COUNT只会在当前连接的库/表上执行，无法聚合所有分片——$list->total()返回的是单分片数据量，不是全局总数 -
LIMIT offset, size被原样下发到每个分片，各取各的“第 N 条”，合并后顺序错乱、数据跳跃（比如第 1 页末尾和第 2 页开头出现同一批时间戳的数据） - 模型或
Db::name()不知道你在哪几个分片上查，也不会自动改写 SQL 或做结果归并 - 即使你手动切换连接（
Db::connect('shard_1')），paginate()仍只作用于当前连接，不会跨连接协调
禁止跳页 + 游标分页（time > ?）是最实用的落地方案
对 C 端用户「下一页」类场景，放弃 offset，改用基于排序字段的游标（cursor-based pagination）是唯一能兼顾性能与准确性的做法。ThinkPHP 本身不内置该能力，但可以干净接入：
- 第一步：确保排序字段（如
create_time）在所有分片上都有索引，且值严格单调或带唯一性兜底（如(create_time, id)联合排序） - 第二步：首次请求不带游标，查第 1 页（
ORDER BY create_time DESC LIMIT 20），拿到最后一条的create_time和id - 第三步：后续请求带上
WHERE (create_time, id) （注意降序时用 <code><），再加LIMIT 20—— 这个条件必须下推到每个分片执行，不能靠 PHP 合并后过滤 - ThinkPHP 中需绕过
paginate()，手写查询：Db::name('order_' . $shard_id)->where($cursorCondition)->order('create_time desc, id desc')->limit(20)->select() - 应用层合并多个分片结果后，再按
(create_time, id)全局排序并截取 —— 数据量可控（每分片最多 20 条），远好于深度 offset 方案
全局查询法（内存归并）只适合小数据量或管理后台
当业务允许牺牲性能换准确性（例如后台导出第 50 页订单），可人工实现「全局视野」：
立即学习“PHP免费学习笔记（深入）”；
- 计算每个分片需取多少条：若共 N 个分片，要取全局第 X 页（
offset = (X-1)*size,size = 20），则每个分片应查LIMIT 0, offset + size（即最多取前(X-1)*size+20条） - 用
Db::connect()轮询所有分片，收集原始结果（注意：别用模型，避免自动附加软删除等干扰条件） - 在 PHP 层用
array_merge()+usort()做全局排序，再array_slice()截取对应区间 - ⚠️ 风险点：页码越大，单次查询传输的数据越多；10 个分片 × 第 1000 页 → 每分片查 20000 条，内存占用和 CPU 排序压力陡增
- 不能用于高并发接口，仅限低频、非实时场景（如运营报表导出）
中间件里动态选库，但 paginate() 依然不能接管分页逻辑
有人试图在中间件中根据 uid 自动路由到对应分库，然后继续用 paginate()——这只能解决「单用户订单查询」，对「全平台按时间分页」无效：
- 中间件可绑定
shard_key并切换连接，但paginate()不感知分片拓扑，也不会自动拆解、下发、归并 - 如果你查的是「所有用户最近订单」，就必须扫全部分片，此时中间件路由反而成了干扰项
- 真正要做的，是在业务方法里显式控制：哪些查询走单分片（可用
paginate()）、哪些必须走多分片（必须手写归并逻辑） - 切记：不要在
paginate()前调用select()或toArray()，否则框架失去插入COUNT和重写LIMIT的机会，变成内存分页，数据量大时直接 OOM
跨库分页没有银弹。游标分页要求排序字段稳定、可下推；全局归并吃资源；而 ThinkPHP 的 paginate() 只是单库抽象，强行套用只会掩盖问题。最容易被忽略的一点：很多团队花一周调通分页，却忘了验证「第 100 页数据是否真的连续不跳」——建议用真实分片数据跑一遍边界 case，而不是只测前两页。
