在美团这种级别的业务场景中，“评价系统”是典型的写多读多、数据量巨大的模块。
面试官抛出“8000万数据查询卡死”的问题，核心不是考你知不知道“分库分表”。
而是考你在复杂查询、索引冗余、架构选型上的深度思考@mikechen
8000万评价表
真实场景假设：表名：t_comment（或 t_review）
行数：8000万
主要字段：id, order_id, user_id, shop_id, score, comment_text, create_time, update_time, pictures 等
高频查询：用户端：我的评价列表（按 user_id + create_time DESC）
商户端：店铺评价列表（按 shop_id + score过滤 + create_time DESC）
运营端：低分评价筛选、统计平均分/好评率
现状：单表查询经常超时，分页深了更慢，分表尝试后商户查询还是卡死。
8000万评价表怎么优化？
别急着分表！先做这些低成本优化（80%场景够用）
诊断瓶颈,必须先说。
打开 slow log + long_query_time = 1；
用 EXPLAIN + FORMAT=JSON 看执行计划；
重点关注：type、rows、Extra（Using filesort / Using temporary / Using where）；
常见罪魁：ORDER BY create_time DESC 没有合适索引 → 全表排序。
索引 & 查询优化（零侵入，效果最快）8000 万评价表，往往“并不是数据大到数据库扛不住，而是索引没建对、SQL 写得太糙”。
你需要思考几个关键点：高频查询的联合索引。
假设评价表典型字段包括：
id、shop_id（商户 ID）、product_id、user_id、created_at、score、status 等。
常见查询：
WHERE shop_id=? ORDER BY created_at DESC LIMIT 10 WHERE shop_id=? AND created_at BETWEEN ? AND ? WHERE shop_id=? ORDER BY score DESC LIMIT 10
对应的索引建议：
(shop_id, created_at)：适合“按商户分页查最新评价”；
(shop_id, score, created_at)：适合“按商户查高分评价”；
尽量避免一个个建单列索引，而是用“多字段联合索引”命中 WHERE + ORDER BY。
最后，分库分表
如果上面的低成本优化做完之后，数据库依然扛不住。
慢查询集中、CPU 高、索引无效果，那才是“值得动分表 / 分库分表”的时刻。
分库分表不是优化，而是“架构升级”，复杂度极高。
明确触发条件
- 单表 > 3000万 ~ 5000万；
- 索引已经优化；
- 缓存已经上；
- 仍然慢；
最后，才考虑分表。