分库分表查询变慢主因是路由失效、聚合未下推、跨节点协调开销大；需坚持精准路由（用分片键/建全局索引）、聚合下推、小表广播、读写分离及强化监控治理。
分库分表后查询变慢，核心问题不在SQL本身，而在路由、聚合和跨节点协调上。优化必须围绕“减少跨库访问”“降低结果集搬运量”“避免单点瓶颈”展开。
精准路由：让查询只打到目标库表
多数性能损耗源于全库扫描式路由——比如用非分片键（如 user_name）查询却没建全局索引，中间件只能广播到所有分片。
- 强制使用分片键（如 user_id）作为查询条件，确保路由可定位到唯一库+表
- 对高频非分片键查询（如手机号、邮箱），建立二级索引表（全局索引表），用异步方式维护，查时先查索引表获取 user_id，再路由查询
- 避免使用 LIKE '%xxx'、OR、函数包裹分片键（如 YEAR(create_time) = 2024）等导致路由失效的写法
合并聚合下推：别把数据全拉到应用层算
sum/count/group by 等聚合操作若在应用层完成，会引发大量冗余网络传输和内存压力。
- 优先使用支持聚合下推的中间件（如 ShardingSphere、MyCat），让各分片各自计算局部结果，中间件再归并（如 sum→各分片sum相加，count→各分片count求和）
- 分页场景慎用 OFFSET，尤其深分页；改用“基于游标的分页”（如 last_id > 10000）+ 覆盖索引，避免跨分片取数再内存排序
- 关联查询尽量拆解：如订单+用户关联，先查订单分片结果，再用 IN (user_id_list) 批量查用户主库（注意 IN 数量控制在 500 内）
读写分离 + 小表广播：缓解热点与关联压力
部分维度表（如省市区、商品类目）更新少、体积小，适合全量复制到每个分片库中，规避跨库JOIN。
- 将不变或低频变更的字典表设为广播表（Broadcast Table），ShardingSphere 等中间件可自动同步并改写SQL为本地JOIN
- 读多写少的业务表，搭配主从架构，在从库做分表查询，主库专注写入，降低锁竞争
- 对实时性要求不高的统计类查询（如后台报表），走单独的OLAP库（如Doris、StarRocks），通过ETL定时同步分表数据，不挤占交易链路
监控与治理：让慢查无处藏身
没有可观测性，优化就是盲调。重点盯三类指标：路由是否命中、跨库次数、结果集大小。
- 开启中间件 SQL 审计日志，标记“BROADCAST”“UNION”“MERGE”等执行模式，快速识别未路由SQL
- 在应用层统一封装分页工具类，自动拦截 offset > 1000 的请求，拒绝执行或触发告警
- 定期分析慢SQL日志，按“跨分片数”“返回行数”“执行时间”三维度排序，优先治理跨3个以上分片且返回超万行的查询
不复杂但容易忽略：一次查询慢，90% 源于没走对路由，而不是SQL写得差。先确认分片键怎么用，再谈索引和执行计划。
