一、分表后的排序分页挑战
在进行 MySQL 分表后，原有的全局排序分页逻辑会面临新的挑战，跨表排序的成本与实现难度显著提高。只有正确理解分表对排序字段、数据分布和查询路径的影响，才能找到高效的排序分页方式。
另一方面，分页边界的可预测性变差，因为不同分表的数据量、索引覆盖状况以及数据分布不尽相同，直接的全局排序往往会导致慢查询和大量的临时数据生成。
排序字段在分表环境中的现实约束
分表后，排序字段可能分散在多张表中，单表内的有序性并不能直接代表全局有序，从而需要改写查询来实现跨表一致的排序效果。
此外，数据倾斜和分区键选择会放大某些分表的查询成本，使得简单的 UNION ALL 叠加难以达到预期的分页性能。
跨表分页成本与可扩展性
传统的分页写法往往依赖一个巨大的有序结果集，然后截取页面区间；然而在分表场景中，这种做法会产生大量的排序和聚合开销，不可在生产环境中直接大规模使用。
为了提高可扩展性，需要结合分表结构和索引设计，尽量让每个分表就地完成排序与筛选，再通过受控的合并策略获得全局排序结果。
二、从索引设计到查询改写的核心原则
统一排序字段与分表键的索引协同
在分表的前提下，为排序字段搭建与分表键组合的覆盖索引，可以在每张分表内快速建立有序检索，从而降低跨表合并的总成本。
示例要点：如果按 create_time 值进行排序，且分表按 user_id 分布，则在每张分表建立 (user_id, create_time) 的联合索引能够降低排序代价，提升分表内的命中率。
-- 每张分表上的推荐索引（按实际分表名调整）
CREATE INDEX idx_user_time ON orders_shard1 (user_id, create_time DESC, id DESC);
CREATE INDEX idx_user_time ON orders_shard2 (user_id, create_time DESC, id DESC);
在实际落地中，索引的前缀选择要贴近查询条件，避免无谓的全表扫描。
分表后查询改写的实用策略
直接对所有分表执行排序再聚合并非高效做法，应采用分表各自排序、局部筛选 + 受控合并的策略，以减小跨表排序的体积。
典型做法包括：在每张分表内部先进行排序和分页筛选，再将结果进行跨表聚合或应用端拼接，最终再进行少量的全局排序与分页截取。
-- 分表内排序与分页的示例
SELECT t.*
FROM (
SELECT id, user_id, amount, create_time
FROM orders_shard1
WHERE user_id = 12345
ORDER BY create_time DESC
LIMIT 100
) AS t
UNION ALL
SELECT id, user_id, amount, create_time
FROM orders_shard2
WHERE user_id = 12345
ORDER BY create_time DESC
LIMIT 100
) AS u
ORDER BY create_time DESC
LIMIT 20;
利用分区视图或中间结果的聚合策略
若数据库版本和架构允许，通过分区视图、物化中间表或应用端缓存等手段来实现跨分区的有序结果，可以显著降低每次分页的成本。
在实现时，务必确保分区视图中的排序字段与分表的排序字段一致，以避免额外的排序开销和数据漂移。
三、排序分页的实战设计要点
分表键与排序键的协同设计要点
在设计阶段，明确分表键（如 user_id、region_id 等）与排序键（如 create_time、order_no 等）的组合关系，以确保每个分表都具备良好的局部有序性。
同时，优先在查询条件涉及的分表上建立覆盖索引，避免回表和额外的数据读取。
跨表查询的路由策略与执行计划
分页请求应经过路由层，将查询分解为对相关分表的局部排序聚合，再在应用端或数据库端完成少量的全局排序与分页。
在执行计划层面，尽量避免全局 SORT 操作的出现，以减少临时表和排序缓冲区的压力。
-- 路由与并行执行的伪代码示例，具体实现依赖框架
SELECT *
FROM (
SELECT id, user_id, amount, create_time
FROM orders_shard1
WHERE <条件1>
ORDER BY create_time DESC
LIMIT 100
) AS s1
UNION ALL
SELECT *
FROM (
SELECT id, user_id, amount, create_time
FROM orders_shard2
WHERE <条件2>
ORDER BY create_time DESC
LIMIT 100
) AS s2
ORDER BY create_time DESC
LIMIT 20;
四、案例对比与优化点
单表与分表在排序分页中的性能对比
在数据规模达到一定量级时，单表的排序分页成本将明显上升，而分表结合本地排序与跨表少量聚合的架构往往能获得更好的吞吐与响应时间。
需要特别关注分表的分布规律与并发度，避免同步瓶颈成为全局排序的制约因素。
常见坑点与优化手段
常见问题包括：数据倾斜导致某些分表热点高、跨表排序时的内存压力、以及索引失效带来的回表成本。
对应的优化手段包括：按热度分配数据、定期统计分表分布、引入缓存层、对排序字段建立覆盖索引等。
-- 统计分表数据分布的示例
SELECT 'shard1' AS shard, COUNT(*) AS total FROM orders_shard1
UNION ALL
SELECT 'shard2', COUNT(*) FROM orders_shard2;
通过对分表分布的持续监控，可以动态调整分表策略和索引结构，确保排序分页在高并发下的稳定性。
