PHP合并后的结果怎么分页-php教程-PHP中文网

合并后分页应优先用数据库union+limit/offset，而非php的array_merge+array_slice；后者仅适用于≤2000条且无复杂排序的静态小数据，否则会导致内存暴增、丢失索引优化、排序失真及总页数错误。

php合并后的结果怎么分页

合并后的结果分页，本质是“先合并、再分页”，但直接在 PHP 里用 array_merge() 或循环拼数组再切片（array_slice()），只适用于小数据量；一旦合并后总数超几千条，内存和性能会明显恶化——这不是分页逻辑错了，而是分页对象错了。

为什么不能直接对合并数组用 `array_slice()` 分页

常见错误是：从多个来源（比如不同表、API、缓存键）取数据，array_merge($a, $b, $c) 后统一算 $offset 和 $limit，再 array_slice($merged, $offset, $limit)。问题在于：

所有数据必须一次性加载进内存，哪怕最终只显示 10 条，也可能拉取上万条原始数据
无法利用数据库索引或游标优化，排序（如 ORDER BY created_at DESC）需在 PHP 层重排，丢失原有序列稳定性
总页数计算失真：合并前各源数据可能有重叠、去重未做，count($merged) 不等于真实逻辑总数
翻页时无法复用已查过的中间结果，每次请求都得重新合并+切片

`array_slice()` 分页仅适用于明确可控的小规模合并

如果你确认合并后总数稳定 ≤ 2000 条（例如配置项列表、本地静态数据聚合），且无需复杂排序或筛选，可用 array_slice()，但必须前置校验：

用 (int) 强转 $_GET['page']，并限制最小为 1：$page = max(1, (int)($_GET['page'] ?? 1));
固定每页条数（如 $per_page = 15），避免传参控制导致越界
合并前去重（如用 array_unique($merged, SORT_REGULAR)），否则 count() 和 array_slice() 行为不可预期
排序必须在合并后、切片前完成，且用稳定算法：usort($merged, fn($a, $b) => $b['time'] $a['time']);

示例片段：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

$data_a = get_from_db('news', ['limit' => 50]);
$data_b = get_from_api('announcements');
$merged = array_unique(array_merge($data_a, $data_b), SORT_REGULAR);
usort($merged, fn($x, $y) => $y['created_at']  $x['created_at']);
$total = count($merged);
$per_page = 15;
$page = max(1, (int)($_GET['page'] ?? 1));
$offset = ($page - 1) * $per_page;
$items = array_slice($merged, $offset, $per_page);

真正可扩展的方案：用数据库 UNION + LIMIT/OFFSET

当合并源来自同库多表（如 posts、pages、products），优先走 SQL UNION ALL，让数据库完成合并、排序、截断——这是唯一能兼顾正确性、性能和总页数计算的路径。

所有子查询字段数、类型、顺序必须严格一致，否则 UNION 报错
用 UNION ALL 而非 UNION，避免隐式去重开销（除非业务真需要）
ORDER BY 必须放在整个 UNION 语句末尾，不能在子查询里写
总记录数必须单独查一次 SELECT COUNT(*) FROM (…UNION ALL…) AS t，不能依赖子查询各自 COUNT 相加
偏移量大时（如 OFFSET 10000），仍会慢；此时应改用基于主键/时间戳的游标分页（WHERE id > ? ORDER BY id LIMIT 10）

典型结构：

(SELECT id, title, 'post' AS type, created_at FROM posts)
UNION ALL
(SELECT id, name AS title, 'product' AS type, updated_at AS created_at FROM products)
ORDER BY created_at DESC
LIMIT :limit OFFSET :offset