有个兄弟去面美团三面被面试官问得汗流浃背。 面试官没问那些虚的直接甩了个业务场景“美团外卖的订单量级你懂的。假如t_order表已经 8000 万行了用户查‘我的订单’经常转圈圈甚至偶尔超时你怎么搞”这兄弟也是个老实人直接把背好的八股文搬了出来“这量级必须分库分表啊索引树太高了拆开了才好使。”面试官听完放下了笔反问了一句“分库分表那是‘伤筋动骨’的架构重构。如果我们工期只给一周且不准引入分布式事务中间件你能不能在单表架构下把这活儿干了”他当时就懵了。其实这题考的不是你会不会用 ShardingSphere而是你有没有“存储治理”和“异构解耦”的实战经验。一、 别迷信“分库分表”那是最后的保底很多兄弟一听数据量大就想拆但你真的考虑过分表后的痛苦吗非分片键查询以前一个 SQL 搞定分表后你按order_id拆那按shop_id查怎么办全库扫描数据库直接 CPU 100%。分布式事务Transactional失灵了你是上 Seata 还是写 TCC 补偿每一个都是 Bug 高发区。工期成本数据迁移、代码改写、回归测试一个月能上线都算你手快。二、 核心方案异构索引 蚕食式归档别死磕 MySQL把压力卸载到专业的组件上。1. 异构索引ES 才是查询的“救命草”不要让 MySQL 既负责高频写又负责多维查。Canal 实时同步监听 Binlog 实时把数据“同步”到 ElasticsearchES。读写解耦历史/复杂搜索比如搜“半年前的奶茶订单”直接路由到 ES。C 端近期查询查最近 1 个月的订单直接走 MySQL 热表速度极快。防坑细节Canal 可能会延迟。我们的策略是下单后 5 分钟内的订单查询强制查 MySQL5 分钟后的逻辑再去查 ES。这样用户感知不到同步延迟。2. 蚕食式归档优雅地剔除“僵尸数据”大表查询慢很大程度是因为冷数据太多把 B 树顶到了 4 层以上且占满了 Buffer Pool。不要直接 DELETE几千万行的DELETE会产生海量 Binlog主从延迟能让你想哭。pt-archiver 蚕食策略用 Percona 的pt-archiver。这玩意儿好在哪它能按行数小批量搬运。方案细节每天凌晨每秒只挪动 500 条数据到冷库/HBase。这种“蚕食”方式主从无感磁盘 IO 几乎没波动。热表始终控制在 500 万行的“轻量”状态索引全在内存里。三、 怎么保证数据不丢闭环思维面试官肯定会问一致性。你要拿出这种“防御性编程”的劲头状态位订单表加个archive_status归档成功后再改状态最后清理。离线核对每天凌晨跑个 Spark 任务对比热库、冷库、ES 三方的数据 Count 值。ACK 机制归档逻辑必须是“先入冷库后删热库”确保即便归档程序崩了数据也还在原地。四、 面试标准回答模板直接拿去用“对于 8000 万规模的订单表我倾向于‘轻量化治理’。存储层面实施冷热分离。利用pt-archiver蚕食清理 3 个月前的非活跃订单把热表规模压在 500 万行以内保住 B 树的 3 层高度。查询层面构建Canal ES 异构索引。将海量的历史搜索和复杂维度查询卸载到 ES 上。稳定性引入离线核对机制做 ACK 闭环确保三端数据最终一致。 这种方案不需要重构业务代码不需要解决分布式事务是性价比最高的打法。”五、 Fox 的避坑口诀大表查询别慌张分库分表非良方。先看冷热分没分再看 ES 强不强。pt-archiver 蚕食走Canal 同步稳如羊。架构解耦思维广Offer 拿得才叫香写在最后在大厂干活最值钱的是“对系统复杂度的控制力”。能用异构索引和归档搞定的绝对不要去动底层存储结构。永远保持核心数据库的“轻盈”与“纯粹”。https://mp.weixin.qq.com/s/NvcM6FSJvq_2wBb_eG1oxg