当前位置：首页 > news >正文

订单表拆成 100 张后，那些要命的查询该怎么做？

news 2026/5/12 20:08:49

分库分表的核心逻辑是**“路由”。
当你按照user_id进行 Hash 取模（比如user_id % 100）来决定数据落在哪张表时，user_id就是你的分片键 (Sharding Key)**。

如果用户的 SQL 是SELECT * FROM order WHERE user_id = 123，中间件（如 ShardingSphere）会瞬间算出这条数据在order_23表，直接把 SQL 路由过去。极其丝滑。

但如果是下面这两种情况呢？

💣 痛点一：非分片键查询（迷失在 100 张表中的 SQL）

场景：用户想通过订单号查订单WHERE order_sn = 'SN999'；或者商家想查自己店铺的订单WHERE merchant_id = 888。
死局：因为你的 SQL 里没有带user_id，分库分表中间件根本不知道这条数据在哪个库哪张表！它只能做一个极其愚蠢且致命的操作：全路由 (Broadcast)。
它会把这条 SQL 同时发给 100 张表，等 100 个结果返回后在内存里合并。瞬间榨干数据库的连接池，系统直接挂掉。

大厂解法 1：ID 基因法 (The Gene Approach)

这是阿里、京东解决order_sn查询的最经典方案。
既然根据order_sn算不出在哪张表，那我们就在生成order_sn的时候，把user_id的基因嵌进去！

假设user_id = 10059，取它的后 4 位0059作为路由基因。
在生成订单号时，用分布式 ID 算法（如雪花算法）生成一串前缀，然后强行把0059拼在订单号的最后面，变成：SN_12345678_0059。
当用户用订单号查询时，中间件截取订单号的后 4 位0059，立刻就能算出它在第 59 张表！完美避免全表路由。

大厂解法 2：异构索引表与 CQRS 架构

如果是商家要查自己的订单（带merchant_id），基因法就行不通了，因为一条订单不能同时携带买家和卖家的基因。
这时候只能用空间换时间：

买家视角：依然按照user_id分库分表，保证买家高并发下单极速响应。
卖家视角/复杂后台查询：引入阿里 Canal 监听 MySQL 的 Binlog。一旦有订单写入，Canal 立刻将数据同步到Elasticsearch (ES)搜索引擎中。
卖家查询、后台产品经理查各种复杂条件组合，全部去查 ES，绝对不碰 MySQL！

🌊 痛点二：跨库分页的 OOM 惨案（内存杀手）

场景：后台管理员要查看全站的所有订单，按时间倒序排列，并且点击了第 1000 页。
SQL：SELECT * FROM order ORDER BY create_time DESC LIMIT 10000, 10

死局：
在单表里，这就是个普通的深分页。
但在 100 张分表里，这就是一场内存大爆炸。
为了保证全局排序的准确性，中间件不能只去每张表拿 10 条数据。它必须去每一张表都执行LIMIT 0, 10010！
也就是说，它会从 100 张表里，总共捞出100 万零 1000 条数据，全部塞进中间件（应用服务器）的内存里！
然后在这个应用的内存中对这 100 万条数据进行二次大排序，最后截取前 10 条扔给前端，把剩下的 99 万多条直接丢弃。

结果：你的应用服务器瞬间 OOM (Out Of Memory) 宕机，CPU 飙升到 100%。

大厂解法 1：业务妥协（游标分页法 Cursor）

这是最高效的解法，但需要说服产品经理。
彻底废弃“跳页”功能，不允许输入页码，只能点“下一页”。

第一次查询（第 1 页）：SELECT * FROM order ORDER BY id DESC LIMIT 10。记录下返回的最后一条记录的 ID，比如last_id = 9990。
点击下一页（第 2 页）：将上一页的last_id带入查询条件：SELECT * FROM order WHERE id < 9990 ORDER BY id DESC LIMIT 10。
优势：因为加上了WHERE id < 9990的条件，无论翻到第几万页，数据库每次都只需要扫描 10 条数据。在分库分表中，中间件也只需要去每张表拿 10 条，完全没有内存压力。这就是各大 App 信息流（如抖音、朋友圈）下拉刷新的底层逻辑。

大厂解法 2：二次查询法 (极其硬核)

如果非要跳页，又不想 OOM，可以采用复杂的“二次查询”。

第一次查询：把LIMIT 10000, 10改写为LIMIT 100, 10（也就是均摊到每个库）。从每个库只拿出极少量的数据。
找到这批数据中的全局最小值（Time_Min）。
第二次查询：把 Time_Min 作为一个BETWEEN条件，再次去各个库进行精准拉取，从而极大地缩小数据集。
(注：这种方案工程实现极其复杂，目前业界更倾向于直接把数据同步到 ES 去做深分页，或者直接限制深分页最大深度为 100 页)。