按月份分表 跨年查询扫了 24 张表 执行计划为什么这么长

订单按 create_time 每月一张表，1 月 5 日查上一年全年数据，中间件生成了 24 条 SQL，页面等了 3.2 秒才出结果。乍看像缓存或者权限的锅，追下去往往不是。

SELECT count(*) FROM t_order_2025
WHERE create_time >= '2025-01-01' AND create_time < '2026-01-01';

追下去是这么回事：查询条件只写了年份范围，路由要把范围内所有月表都算进去，12 个月乘以库数就是 24 个目标。每个目标单独建连接、单独返回结果，再在内存里归并。

「时间分表跨月查询」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。

偶发问题先统计频率，一小时几次和一天一次，查法完全不同。

具体做法是，查询条件补上明确的时间上下界 减少命中月表；跨多月的统计挪到按年归档表或离线汇总；需要保留明细的按季度建表 降低表数量；对路由结果加日志 确认目标数符合预期。

验收就看一点，同样的查询只命中一张年表 耗时降到 200 毫秒以内。