张云雷宝宝先说一个我自己踩过的真实场景：订单表从单库单表一路冲到三千万行，慢查询把主库CPU干到80%以上，DBA天天在群里@我。当时第一反应就是"上分库分表"，好像只要拆了就万事大吉。等到真拆完，跨库join直接废了、聚合统计慢到怀疑人生、订单列表按时间倒序翻页翻到后面直接走全表扫描，这才意识到一个残酷的事实——分库分表只是把单机瓶颈换成了分布式复杂度，它从来都不是银弹。
这篇文章不聊那些"从入门到精通"的教科书内容，就聊我在真实项目里被逼着走出来的三条路：中间表、二次分库分表、ES中间件结合。它们不是互斥的替代方案，而是按业务场景组合着用的。我会把为什么这么选、怎么落地、踩了哪些坑、最终效果如何，一次性讲透。
1. 分库分表的真实代价：从单库瓶颈到分布式复杂性
很多人对分库分表的理解停留在"数据多了就拆"的层面，但拆完以后系统面临的问题，远比单库慢查询更棘手。先说清楚分库分表到底解决了什么，又带来了什么，你才知道后面那些补救方案是为什么存在的。
1.1 单库单表扛不住时，瓶颈到底在哪里
单库单表的数据量上涨后，瓶颈通常不是一个点，而是三个点同时逼近极限。
第一个是存储容量和IO。MySQL单表数据量超过两千万行以后，B+树索引层级加深，随机IO次数增加，即使命中索引，回表的代价也明显上升。磁盘空间、binlog体积、备份恢复时间，全都在指数级恶化。第三个点是连接数和CPU。单库的连接数上限是有限的，业务高峰期一旦连接被打满，所有请求都排队，表现为接口RT从几十毫秒飙到几秒甚至超时。
我见过最典型的场景是流水类业务：一天几百万条数据入账，单表一个月就上千万行，查询条件又千奇百怪——按用户查、按时间查、按业务类型查、按状态查。这种情况下单库单表确实到了瓶颈，分库分表方向本身没错。但问题在于，拆完以后你不能只盯着"数据分散了"这个好处，还得面对一个完全不同的、复杂度高一个量级的系统。
1.2 分库分表后，最先爆发的三类问题
拆完库表后，最先让我崩溃的三类问题，几乎每个做分库分表的人都会遇到。
第一类是跨库join直接不可用。以前一条SQL就能把订单、商品、店铺三张表join出来，拆完之后数据散落在不同的物理库，join从数据库层面就做不了了。你得在应用层手动拼装，先查订单分片，再拿着订单里的商品ID去商品分片批量查，最后在内存里做关联。查询次数变多，网络开销变大，代码复杂度起来，接口RT也肉眼可见地涨。
第二类是分布式事务的范围收敛问题。原来一个本地事务能搞定的事，拆库后涉及多个库的写入，就得引入分布式事务方案。XA协议太重，TCC开发成本太高，可靠消息最终一致性又需要额外的基础设施。很多时候为了保住核心链路的一致性，非核心数据只能接受异步同步的延迟，业务上还得跟产品经理解释"为什么刚下的单在列表里看不到"。
第三类，也是最容易被忽视的，是聚合查询和全局维度的操作几乎全军覆没。分库分表后，所有查询都依赖路由规则——按订单ID取模路由到具体分片。但业务方不会总按订单ID查，他们可能按买家查、按店铺查、按时间范围查、按商品模糊搜索。路由键没覆盖到的查询，就只能把所有分片都查一遍然后合并结果，数据量大时这个"扫全分片"的代价比单库还恐怖。
此外还有全局唯一ID、分页排序错乱、数据倾斜、扩容时rehash导致的数据迁移等等。这些问题的核心就是：分库分表是水平扩展的手段，但它只擅长"按分区键的点查"，一旦查询维度超出分区键，整个系统就在为这个"超出"付出代价。
这时候你就得接受一个现实：光靠分库分表解决不了所有问题，必须配套其他手段来补短板。下面三种方案，就是我实战中针对不同问题采用的解法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 中间表方案：用空间换确定性，解决跨表关联的笨办法
很多人一听"中间表"就觉得低端、不优雅，好像不做分布式就丢人了。但我要说一句公道话：在数据量可控、查询模式固定的场景下，中间表可能是性价比最高的方案，没有之一。
2.1 中间表的本质是"预计算+旁路查询"
中间表的思路其实很简单：业务里高频的跨表关联查询，如果每次都实时去多张表拿数据再拼装，代价太大，那就提前把这张"拼装好的结果"存下来，查询时直接读它，不用再join。
举个例子。电商订单列表页要展示：订单号、商品名、商品主图、店铺名、买家昵称、订单金额、订单状态、下单时间。在分库分表前，这张列表用一条SQL join订单表、商品表、店铺表、用户表就能搞定。分库后，订单在订单分片，商品在商品分片，店铺和用户又在各自的库，join直接没法做。
我的做法是冗余一张订单列表宽表，也叫中间表。这张表包含列表页需要的所有字段，数据在订单创建、商品改价、店铺改名、买家换昵称等事件发生时，通过异步任务同步更新。查询时单表单查，按照订单ID或买家ID路由到对应分片去读，速度和稳定性都有保障。
从本质上看，中间表就是"预计算+旁路查询"——把实时join的查询代价前置到写入/更新流程里，让查询路径变得极其简单。和缓存方案的区别在于，缓存是"查不到再回源"，中间表是"数据始终存在，只是可能有一点延迟"。对延迟不敏感的业务，中间表比缓存更简单可靠。
2.2 中间表设计的关键：粒度、字段冗余与一致性
中间表不是"随便建一张宽表就行了"，设计不好反而会变成新的瓶颈。我提炼出三个关键点。
粒度决定一切。 一张中间表只对应一种查询场景，不要试图做一张"万能宽表"。订单列表是订单列表，买家订单历史是买家订单历史，两者查询维度不同，合并到一起反而让表变的臃肿、更新逻辑复杂、索引难以设计。我见过有人试图把订单、售后、物流信息全塞进一张中间表，结果那表比原始订单表还大，根本没有达到"精简单查"的目的。
字段冗余要克制。 中间表的核心是让查询不需要回源，但也不是所有字段都得冗余进去。原则是：高频列表需要的展示字段冗余进来，低频详情页需要的字段不冗余，查询时回源拿即可。 比如商品详情、售后记录这些，不必塞进中间表。字段冗余过多，同步更新的链路就会拖得很长，任何一个字段更新失败都会导致整张表的数据不可信。
一致性是最大的坑。 中间表的数据来自多张源表，这些源表分布在不同的服务里，同步更新天然就存在一致性问题。这里我采用的是"事件通知+异步刷新+定时对账"三层保障。第一层，源表变更时发送MQ消息，消费端收到后更新中间表；第二层，如果MQ消息丢失或消费失败，中间表数据就会和源表不一致，所以每天凌晨跑一次对账任务，按ID比对源表和中间表的关键字段，不一致就刷新；第三层，对账也发现不了的场景，比如源表数据被物理删除导致中间表没有对应事件，需要定期做全量扫描或接受一定程度的脏数据。
这个三层保障看着繁琐，但它能保证在绝大多数情况下，中间表的数据是"最终一致"的。对用户来说，列表页出现几秒到几十秒的延迟是可以接受的，但出现"下单后列表页永远找不到"就是不可接受的，所以对账任务不能省。
2.3 一个完整的中间表落地示例
我拿订单列表中间表来拆解一下实际落地过程。
第一步，确定查询场景和路由键。 这个列表页的查询维度是"买家ID"，我按买家ID % 64把中间表拆到64个分片，这样查询时能精确定位到单个分片，不会触发扫全表。中间表主键是买家ID + 下单时间 + 订单ID的复合键，保证同一个买家的订单按时间排序后，分页查询时能走索引。
第二步，定义中间表结构。 冗余字段包括：订单ID、订单号（给用户看的）、买家ID、买家昵称、商品ID、商品标题、商品主图URL、店铺ID、店铺名称、订单金额、订单状态、下单时间、支付时间、收货人省份城市。这些字段覆盖了订单列表页的90%的展示需求。不冗余的字段有：商品SKU明细、售后状态、发票信息等。
第三步，同步链路设计。 订单服务创建订单成功后，发送OrderCreated消息；商品服务改价后，发送ProductChanged消息；店铺服务改名后，发送ShopChanged消息。一个消费者服务监听这些消息，按订单ID查一次源数据（或直接消费消息里的数据），然后做INSERT ... ON DUPLICATE KEY UPDATE更新中间表。
这里有个细节：不可能所有消息都实时消费，高峰期MQ堆积时中间表会有延迟。我在更新逻辑里加了"版本号"字段，每次更新时比较消息里的版本号和中间表里的版本号，只处理更新的数据，避免旧消息把新数据覆盖掉。
第四步，查询侧改造。 应用层的订单列表查询从原来的"多表join"改为"直接查中间表分片"。查询参数是买家ID、分页参数、筛选条件，SQL变成了简单的SELECT ... FROM order_list_wide WHERE buyer_id = ? ORDER BY order_time DESC, order_id DESC LIMIT x, y。没有了join和子查询，单次查询RT稳定在10毫秒以内，而且对分片的选择是确定的，不会因为业务量增长而出现性能波动。
第五步，兜底策略。 如果中间表的同步链路挂了（比如MQ堆积导致延迟超过分钟级），查询侧要有降级方案。我的做法是：监控中间表"最新更新时间"字段，如果数据超过5分钟没更新，就切换回源库查询——源库虽然要做join，但至少不会让用户看到空列表或缺失数据。降级开关通过配置中心动态下发，不需要发版。
中间表方案适合什么场景？简单说：查询模式相对固定、数据量在可控范围内、对实时性要求不极端。如果你的列表页有几十种筛选组合、排序字段还经常变，那中间表就会变成一个"大杂烩"，更新逻辑复杂到维护成本超过收益，这时候就需要考虑其他方案了。
3. 二次分库分表的触发条件与改造路径
第一次分库分表之后，系统稳定运行一段时间，你以为可以高枕无忧了？不一定。业务增长和查询模式变化，会把"看似合理"的拆分方案逐步逼到墙角，这时候就面临第二次分库分表。
3.1 第一阶段拆分后，哪些信号说明该二次拆分了
我总结过我自己的项目里出现过的四个典型信号。
信号一：单分片数据量再次逼近极限。 假设第一次按订单ID % 16拆了16个分片，每个分片的数据量大约500万行。一年后总数据量翻倍，单分片到1000万行，索引性能下降、存储空间吃紧，老问题卷土重来。这时候如果你还要继续用这套路由规则，就需要把16个分片扩容到32个或64个，这就属于二次分库分表。
信号二：数据倾斜严重。 取模分片天然会碰到这个问题——某些买家或店铺的数据量特别大，导致个别分片的压力远高于其他分片。比如一个头部店铺的订单量是普通店铺的几百倍，按店铺ID取模后，同一个分片里可能有几十个头部店铺，而其他分片只存放长尾小店铺，负载完全失衡。极端情况下，某些分片的主从延迟在高峰期根本追不上，业务方投诉"数据怎么查不到"。
信号三：分区键与查询模式不匹配。 这是最常见的二次拆分诱因。第一次设计时可能按照订单ID分片，但业务发展后，最高频的查询变成了"按买家查订单列表"。按订单ID分片意味着一个买家的订单散落在多个分片里，每次查询都得扫全部分片再合并。查询维度已经变了，路由规则不跟着变，系统整体性能就会被拖垮。
信号四：容量已经超出单库可管理的上限。 即使分片没有数据倾斜，总数据量达到一定程度后，单分片的备份、扩容、恢复时间都会长到无法接受。数据库运维的复杂度会随着分片数量的增加而大幅上升，这时候再不想办法做架构升级，DBA就要打人了。
这四个信号不一定同时出现，但出现任何一个，你都得认真评估是不是该做二次改造了。等到业务高峰期被慢查询搞挂的时候再动手，代价只会更大。
3.2 二次拆分的三种路径对比：扩分片、分区键调整、异构路由
二次分库分表不是简单地把分片数翻倍，它有几种不同的路径，每种路径的改动范围和风险差异很大。
路径一：扩分片（水平扩容）。 这是最直观的做法，把16个分片扩到32个或64个。但直接改hash规则会导致一个问题——原来按订单ID取模16的数据，现在取模32，路由结果完全变了，意味着所有存量数据都得重新分布。这个迁移成本在数据量大时非常恐怖。所以更稳妥的方式是引入一致性哈希，保证大部分数据不需要迁移，只有一部分数据需要重新分配。一致性哈希的缺点是实现复杂度高、路由规则不好排查，但又是在线扩容时最务实的选择。
实际操作时，我建议用"双写+平滑迁移"的方式来做扩分片：
- 新增加分片，并保持新旧两套路由规则同时存在。
- 写入请求同时写老分片和新分片，读请求继续走老分片。
- 后台任务按ID范围分批把老分片的数据全量搬运到新分片，搬运时要比对时间戳，防止旧数据覆盖新写入的数据。
- 全量数据校验通过后，把读流量灰度切到新分片。
- 最终确认无误后，下线老分片路由规则。
这个过程看着不复杂，但每一步都有很多细节坑，比如"双写期间老库的数据被删除，新库没同步删除"这种问题，就需要额外引入墓碑标记来处理。总的来说，扩分片是路径里最"物理"的，也是最常规的。
路径二：分区键调整。 比如原来按订单ID分片，现在想按买家ID分片。这种情况通常是因为查询模式发现变化，业务方最关心的是"某个买家看到了什么订单"。数据分布规则变了，所有数据都得重新路由和迁移，本质上就是全量重构。而且分区键调整会影响所有上下游系统——原来按订单ID查询的接口、报表任务、定时脚本，全都得跟着改。这通常是成本最高、风险最大的路径，一般只在万不得已时才选。
路径三：异构路由。 这是我在实际项目中比较推荐的思路：不强制修改底层分片规则，而是引入一层"路由中间层"——根据不同的查询条件，把请求分发到不同的数据源。这里的"异构"就是指：底层数据分布可以有不同的分区键，上层通过路由层透明地屏蔽这些差异。
举个例子。订单数据继续按订单ID分片，但为了支持"买家查询订单列表"，我单独构建一份按买家ID分片的"买家订单索引表"。这个索引表不存全量数据，只存买家ID + 订单ID + 必要排序字段。查询时先走索引表定位到订单ID，再回订单分片拿完整数据。这本质上就是中间表思想的延伸，只是它在路由层面帮你做了"二次定位"。
三种路径不是非此即彼的，实际项目里经常组合着用。比如前期先做异构路由解决查询维度的痛点，后期数据量再涨，再对某些分片单独扩容。
3.3 二次拆分的数据迁移与灰度切流实操
二次拆分最怕的不是代码改不好，而是数据迁移出问题。我踩过最大的坑就是存量数据和新增数据对不上号，导致同一个订单在列表里出现了两条，一条是老分片里的旧数据，一条是新分片里的新数据。
我梳理了一套相对成熟的迁移流程，供参考：
第一步，盘点存量数据和依赖关系。 明确被迁移的表有哪些、数据量多大、上下游依赖有哪些、查询路由规则是什么。这一步不做好，后面迁移一定会出乱子。
第二步，双写改造。 写入操作同时写旧存储和新存储，为了保证两侧数据一致，需要引入一个"去重键"。比如订单ID在两侧都是唯一的，写入时用INSERT IGNORE，避免重复插入；更新操作记录版本号，只保留最新版本。
第三步，数据全量校验。 后台任务比对旧库和新库的数据量、抽样比对关键字段，发现差异就记录日志并触发修复任务。校验不是一次性的，要全量校验后做增量校验，确保双写期间没有出现数据漂移。
第四步，灰度切读。 读流量按百分比灰度切到新存储。先在预发环境验证，再在线上放量1%、5%、10%、50%，每次放量后观察错误率、RT、数据一致性。一旦发现异常，立即切回旧存储。
第五步，下线旧存储。 新存储稳定运行一段时间后（我一般至少观察一周），把旧存储的数据备份、确认不再被依赖，再下线。
这套流程的最大价值在于：每一步都有回滚的点，不会出现"要么全成功、要么全失败"的赌局。 二次分库分表不是一次性革命，而是一系列可以观察、可以回退的小步骤叠加。
4. ES中间件模式：把复杂查询交给搜索引擎，把简单KV留给数据库
中间表和二次分库分表能解决跨库join、数据倾斜、路由错配这些"已知的"问题，但有一种需求它们都搞不定——复杂的模糊搜索、全文检索、多维度的聚合统计。这时候就需要把ES请进来，作为数据库之外的查询中间件。
4.1 为什么最终还得引入ES：分库分表后的通配查询与聚合分析
分库分表之后，我最头疼的业务场景是运营后台的"订单综合搜索"：运营同学输入"商品名称包含某个关键词，或者买家昵称匹配某个字符串，或者订单金额在某个区间，还要按店铺维度做销售统计"。这类查询根本没法通过路由规则定位到具体分片——关键词匹配、模糊搜索、组合筛选、聚合统计，全都得扫全部分片。扫16个分片再合并结果，慢不说，结果还不准（因为每个分片只返回部分数据，合并后分页会错乱）。
中间表也救不了这个场景，因为运营的筛选条件千变万化，你不可能把所有组合都冗余到中间表里。数据库全文索引对中文分词支持较差，LIKE '%keyword%'扫全表更是灾难。
所以最终方案就是把ES作为查询中间件：业务数据通过binlog或MQ同步到ES，建立倒排索引，所有复杂查询先走ES拿到满足条件的ID集合，再回MySQL按ID批量取完整数据。 分库分表后的MySQL依然承担核心的KV查询和事务写入，ES承担复杂的搜索与分析场景，两者各司其职。
这里有一个关键认知：ES和分库分表不是二选一的关系，而是互补关系。分库分表解决的是"确定性KV查询的水平扩展"，ES解决的是"不确定性复杂查询的检索能力"。数据可以先写入MySQL分片，再异步同步到ES，两个系统保持数据最终一致即可。
4.2 ES与分库分表同步链路的两种可靠架构
把数据从MySQL同步到ES，常见的有两种架构：binlog订阅模式和应用双写模式。
binlog订阅模式，典型代表是Canal + MQ + 消费者。Canal伪装成MySQL从库，读取主库的binlog，把数据变更事件发送到MQ，消费者拿到事件后写入ES。这个方案的好处是：对业务代码无侵入，MySQL的任何写入都能被捕获到，不用担心漏掉某个update操作。坏处是：链路长、组件多，binlog解析格式复杂，一旦Canal挂掉或者binlog被清理，增量数据就可能丢失，必须配合定时全量对账来修复。
应用双写模式，就是在业务代码里，写入MySQL成功后再主动发一条MQ消息或直接调用ES写入接口。这个方案的优点是有业务语义，可以按需决定哪些数据需要进ES，逻辑清晰；缺点是侵入性高，如果某个服务忘记了双写，ES数据就会漏掉，而且一旦MySQL事务回滚但消息已经发出，就会产生脏数据。
我在实际项目中采用的是"binlog订阅为主、应用双写兜底"的组合方案：
- 核心交易链路的数据用binlog订阅同步到ES，保证大部分数据能准实时进入ES。
- 对于与核心交易无关的配置类数据（比如店铺信息、商品扩展属性），用应用双写模式主动写入ES集群中的一个独立索引。
- 每天凌晨跑对账任务，比对MySQL和ES的数据量，并把差异数据重新灌入ES。
这条组合方案的核心原则是：确保任何一条数据变更都不会因为单点故障而彻底丢失，宁可重复消费，不可漏掉。
ES索引设计上，我建议走"宽表模式"——和中间表类似，把订单列表页和搜索页需要的维度字段都冗余到一个ES文档里。文档的 _id 用订单ID，路由字段用买家ID或店铺ID（按业务查询习惯定），这样ES的分片也能支持一部分基于路由字段的聚合查询。
4.3 ES查询失败时如何降级兜底
引入ES最怕的一件事就是ES集群抖动或故障，导致所有搜索接口直接挂掉。ES再快、再强大，它也是一个分布式系统，也会遇到脑裂、慢查询、分片恢复等问题。所以降级兜底方案必须在架构设计时就考虑进去，不能等出了故障再想。
我的降级策略分三层：
第一层，限流降级。 在搜索服务层配置线程池和信号量隔离。ES集群的处理能力是有限的，高峰期如果搜索请求量暴涨，先让一部分请求快速失败（返回默认数据或空结果），保住核心交易链路的稳定性。搜索场景不像交易场景那样对成功率有硬性要求，牺牲一部分搜索体验换整个系统的稳定是值得的。
第二层，索引降级。 如果单个索引数据不一致或者搜索结果异常，可以通过配置中心动态切换查询源。比如"订单搜索索引"出问题时，切换到备用的"订单搜索索引-只读副本"；如果所有ES索引都异常，降级到MySQL的LIKE查询——虽然性能差，但至少能返回结果不报错。
第三层，关键字降级。 运营后台的复杂搜索用ES，但对于API开放平台的高频简单查询（比如按订单号精确查询、按买家ID分页查列表），我始终保留一条MySQL直查路径。也就是说，ES只负责"复杂的、非确定性的搜索"，简单查询永远走MySQL分片。这个设计让系统在ES故障时，核心查询能力仍然完整。
这里有个实用建议：ES集群的监控必须做到主流程里。 我经历过ES集群JVM Old区打满、慢查询拖垮整个搜索接口的事故，事后复盘才发现监控告警配置有漏洞。现在我的监控项包括：ES集群节点CPU、JVM堆内存使用率、查询QPS和RT、bulk写入速率、分片健康状态、Merge线程池活跃数。任何一个指标超过阈值，都要能在5分钟内触达值班人员。搜索中间件不是架完就完事的，持续观察和运维才是核心。
5. 三种方案如何组合：一个经过验证的架构决策树
前面分别讲了中间表、二次分库分表、ES中间件结合，但在真实系统里，这三种方案不是孤立存在的，而是根据业务场景组合使用。我总结了一个经过实际项目验证的决策思路。
5.1 什么场景选中间表，什么场景选二次拆分，什么场景选ES
我把订单系统的查询场景归为三类，每一类对应一种方案：
第一类：高频、固定模式、低延迟的列表查询。 典型如"买家订单列表""店铺商品列表""商家订单管理列表"。这类查询的过滤和排序条件相对固定，路由键明确，使用中间表最合适。中间表按买家ID或店铺ID分片，查询走单分片，速度和稳定性都最好。
第二类：数据量或查询模式突破原设计边界。 典型信号是单分片数据量过大、数据倾斜严重、查询维度与原分区键不匹配。这时候考虑二次分库分表。但二次拆分成本高、风险大，建议先用路由中间层（异构路由）过渡，比如先用"买家订单索引表"解决查询维度问题，数据量继续涨后再考虑扩分片。
第三类：复杂的多维搜索与分析。 典型如运营后台组合筛选、关键词搜索、按商品/店铺/时间段做聚合统计。这类查询使用ES中间件最合适，MySQL继续保持"KV查询+事务写入"的定位。
这三类场景经常同时存在。一个完整的订单系统，可能是这样的组合：
- 订单主数据按订单ID分片，作为数据最终一致性的事实源。
- 买家订单列表走"买家订单宽表"（中间表），按买家ID分片。
- 运营后台的复杂搜索走ES索引，通过binlog订阅保持同步。
- 订单读多写少的核心详情页，在最上层加一层Redis缓存。
这个组合的架构里，每个组件只承担自己最擅长的任务：MySQL管事务和确定性查询，中间表管高频列表，ES管复杂搜索，缓存管热点。每一个环节都有明确的适用边界，也有明确的降级路径。
5.2 组合架构落地时最容易踩的五类坑
方案选好了，架构设计完了，落地时还是会踩坑。我总结五类最常见的问题，每一条都是真实项目里的血泪教训。
坑一：中间表同步延迟导致的数据不一致，引发用户投诉。 用户下单后立刻去订单列表页，发现订单不在，于是反复刷新、投诉。这一般是MQ消息积压或者消费失败导致中间表没及时更新。解决方案还是前面说的：对账任务不能省，另外在核心节点（比如下单成功页）加一个"强制刷新中间表"的钩子，让用户下单后第一次查列表时，如果中间表查不到，就回源查一次并主动更新中间表。
坑二：二次分库分表时，新旧路由规则没做好灰度，导致数据查不到或重复。 双写期间，如果老规则和新规则的路由结果不一致，同一个订单可能被写入不同的分片，查询时又因为灰度比例不同，同一用户在不同请求下看到不同数据。解决思路是"路由切换必须按用户维度灰度"，而不是按请求比例灰度。按用户ID哈希的灰度意味着同一个用户始终走同一条路由，不会出现同一用户一会儿看到新数据一会儿看到老数据的情况。
坑三：ES同步链路数据延迟，导致搜索结果与实际库不一致。 运营后台看到一条订单的"已支付"状态，但在ES搜索里还是"待支付"。这类问题的根源是同步链路消费速度跟不上高峰期写入速度。我的处理方式是：对延迟要求高的状态变更（如支付结果），在应用层双写一份到ES的独立状态字段；对延迟不敏感的展示类数据，接受秒级延迟。
坑四：分片间隙导致全局分页错乱。 分库分表后，如果按全局维度做分页，比如"第1000到1020条"，每个分片都要先取前1020条再合并排序，最后再截取，这种方案在数据量大时性能极差，而且分片间隙会导致结果不准确。ES中间件模式下，from + size分页超过1万条也有类似问题。更稳妥的方式是用"游标分页"（search_after），或者直接限制深度分页，让产品侧接受"只展示前N页"。
坑五：过度设计。 数据量只有几百万行，查询也不复杂，就一直想着"为未来做准备"而上分库分表 + ES。最后系统复杂度上去了，问题解决了吗？没有，反而因为分布式事务、数据一致性、运维复杂度，引入了一堆原本不存在的问题。技术方案的选型永远以当前面临的真实问题为准，而不是以技术趋势为准。
6. 最后分享几个实际运维中的细节
一套组合架构能跑得稳，光靠选型和设计不够，运维细节同样关键。我把实际维护中的几个心得也一并说出来。
监控优先级要分清。 中间表的"数据新鲜度"是最重要的指标，我每天的巡检第一件事就是看各分片中间表的"最新更新时间"曲线。ES集群的JVM老年代使用率要重点关注，我见过很多ES集群挂掉都是从JVM内存打满开始的。分库分表的话，各分片的连接数、慢查询数、数据增长趋势，每周要出一份趋势报告。
变更一定要克制。 分库分表、中间表、ES这些组件，一旦上线，变更代价都非常大。任何表结构变更、索引调整、分片规则修改，都要先在预发环境全流程验证。我给自己定的规矩是：涉及路由规则或索引结构的变更，必须双人评审，而且要记录变更前后的性能对比数据。
业务侧要做好接受"最终一致"的准备。 中间表有延迟、ES有同步延迟、分片之间可能有短暂的不一致，这在分布式系统里是常态。和产品经理沟通时要提前说清楚，哪些场景的数据是强一致的，哪些是最终一致的，让业务方对用户承诺时心里有数。
不要把所有鸡蛋放一个篮子里。 即使有了ES、中间表、缓存，MySQL分片依然是数据的事实源和最后的兜底。我在架构里始终保留着一条"MySQL直查"路径，一旦上层组件全部异常，至少还有一条路能返回数据，哪怕慢一点、结果不完整，也比接口直接500强。
分库分表不是银弹，这句话是我用一次次故障换来的体会。但它也不是不能碰的禁区，关键看你是否清楚它的适用边界，是否愿意为它配套上一整套补齐短板的机制。中间表、二次分库分表、ES中间件结合，这些手段没有哪个是"银弹"，组合起来使用，才能让系统在一波又一波的增长中站稳脚跟。