不能直接用 UNION + LIMIT 做跨表联合分页，因 UNION 结果集无法保证全局顺序，ORDER BY 仅作用于最终结果，导致分页偏移错乱；MySQL 8.0 前还不支持子查询中使用 LIMIT。
为什么不能直接用 UNION + LIMIT 做跨表联合分页
因为 UNION 结果集无法保证全局顺序，尤其当两个表的排序字段（比如 created_at）存在时间重叠或空值时，ORDER BY 只作用于最终结果，而分页偏移量 LIMIT 20,10 会把“逻辑上第21–30条”切碎——可能前15条来自表A、后5条来自表B，下一页又变回表A主导。更麻烦的是，MySQL 8.0 之前不支持 UNION 中单独对子查询加 ORDER BY 和 LIMIT，强行加会报错 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'。
用临时表 + 全局序号实现稳定分页
核心思路是：先把两表数据按统一规则合并、排序、编号，再按编号范围取页。关键不是拼SQL，而是控制生成序号的确定性。
- 先用
INSERT INTO ... SELECT把两表数据归并进带自增主键的临时表（如temp_union_page），插入时显式ORDER BY created_at DESC, id DESC确保顺序一致 - 临时表结构必须包含原表标识字段（如
source_table ENUM('posts','comments')）和原始ID（如original_id），否则查到数据后无法反查详情 - 分页时不再用
LIMIT offset,row，而是查SELECT * FROM temp_union_page WHERE row_num BETWEEN ? AND ?，其中row_num是你插入时用变量或窗口函数生成的序号 - MySQL 8.0+ 推荐用
ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC)直接在SELECT中生成序号，避免临时表IO开销
PHP中封装分页逻辑的关键点
不要让前端传 page=3 就直接算 offset=20，因为跨表数据总量未知，total_count 不能靠 COUNT(*) 一次算准（UNION COUNT 成本高且不准）。
- 首次请求时，用
(SELECT COUNT(*) FROM posts) + (SELECT COUNT(*) FROM comments)做粗略总数，用于渲染页码栏——用户要的是体验连贯，不是绝对精确 - 每次分页查询都带
SQL_CALC_FOUND_ROWS（仅限MySQL 5.7及以下；8.0+ 改用SELECT FOUND_ROWS()配合子查询）或更稳的方式：查一页数据（如10条）的同时，用SELECT COUNT(*)对当前排序条件下的全量做估算（加合适索引！） - 把分页参数和排序规则一起哈希成缓存key，例如
md5("union_page_v1_posts_comments_created_desc_". $page . "_" . $per_page)，避免重复计算 - 务必检查
source_table字段再决定调用哪个模型查详情，别写死成Post::find($id)—— 万一$id来自comments表就查错了
性能陷阱：什么时候该放弃联合分页
如果两个表数据量级相差太大（比如 posts 有10万行，comments 有2000万行），或者排序字段没有有效索引，UNION + ORDER BY 会触发 filesort，执行时间从毫秒级跳到秒级。这时不如换策略：
- 改用时间分区：只查最近7天的
posts和最近1天的comments，用created_at >= ?条件缩小范围 - 前端分层加载：先渲染
posts分页，滚动到底部再 AJAX 加载comments，用不同接口隔离压力 - 物化视图思路：每天凌晨用
EVENT把合并结果写入一张宽表，分页直接查这张表（需权衡实时性）
跨表联合分页真正的难点不在语法，而在排序一致性与数据边界判断——比如两条记录 created_at 完全相同，谁排前面？这个逻辑必须在PHP和SQL两端严格对齐，否则翻页会漏数据或重复。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
