mysql分表后如何查询：多方案实操取舍

mysql分表后如何查询，主流可落地的查询方式包含全局索引查询、路由规则直查、unionall汇总查询、中间件代理查询四种，不同方式适配的数据量、查询场景、开发成本差异明显，中小数据量简单查询优先用路由直查，跨表批量统计用unionall，海量数据高并发场景优先采用Sharding-JDBC中间件，全局索引仅适合低频模糊查询，所有方式均无法规避跨表查询的性能损耗，单表数据量低于500万、查询仅命中单表时，分表查询优势基本无法体现。

mysql分表路由直查方法

你可以依托分表的核心路由规则直接定位单表查询，常见的分表规则包含取模分表、时间范围分表、区间分表三类，这是性能最优的分表查询方式。取模分表场景下，你只需对查询条件中的分片字段执行相同取模运算，算出数据所在的物理表名，直接单表查询即可，比如用户ID按4表取模分表，查询用户ID为100的数据，通过100%4=0，直接查询user_0表。时间分表场景下，根据查询的时间范围匹配对应日期、月份、季度分表，精准定位目标数据表。该方式仅访问单张物理表，查询耗时和单表查询基本一致，并发压力较小。

路由直查的硬性适用边界非常明确，查询必须携带完整分片字段条件，无分片字段、分片字段条件模糊的查询，无法使用该方法。

mysql分表unionall汇总查询方法

无分片字段、需要跨多张分表批量查询统计数据时，你可以使用unionall拼接所有相关分表结果，摒弃union去重逻辑，减少额外计算开销。比如按月份分表的订单表，查询一季度数据，可拼接order_01、order_02、order_03三张表的查询语句，合并结果集。该方法无需改造架构、无需新增中间件，纯SQL即可实现，开发成本极低，适配线下统计、后台报表、低频批量查询场景。

该方法性能短板突出，拼接的分表数量越多，SQL执行效率越低，高频高并发接口禁止使用此查询方式。

mysql分表中间件代理查询方法

业务高频、海量数据、复杂跨表查询场景下，你可以使用Sharding-JDBC、MyCat两款主流分表中间件实现透明查询，这是企业级项目的主流解决方案。中间件会自动解析SQL、识别分片规则，自动路由至对应物理分表，跨表查询自动完成结果合并，业务层无需手动拼接表名和SQL，查询写法和单表查询完全一致。其中Sharding-JDBC为客户端中间件，无独立服务节点，性能损耗较低；MyCat为服务端中间件，适合分布式集群架构。

国内互联网企业90%以上的MySQL分表业务，均采用Sharding-JDBC5.2.x及以上版本实现查询路由，适配绝大多数电商、金融、政务业务场景。

mysql分表全局索引查询方法

针对非分片字段的精准查询需求，你可以建立独立的全局索引表实现查询，全局索引表存储非分片字段与主键、分片字段的映射关系。查询时先查全局索引表，获取目标数据的分片字段值，再通过路由规则查询对应分表数据，两步完成查询操作。该方式解决了非分片字段无法精准定位分表的痛点，适配手机号、身份证号等唯一非分片字段的精准查询场景。

全局索引表需要同步主分表数据，会增加数据写入、更新的冗余开销，高频更新的业务字段不适合搭建全局索引。

禁止使用union替代unionall执行跨表查询。

union会自动执行全局去重排序操作，相较于unionall，会多消耗30%以上的查询耗时，无重复数据校验需求时，该操作完全冗余。

分表查询的性能上限由分片规则合理性决定，无序取模分表的跨表查询效率，明显低于有序时间分表。