千万级大表到底该不该上分区表？三种路线的取舍

背景：最近带团队做一张 2 亿行的订单流水表治理，业务方一上来就说"先分区吧，分区快"。我犹豫了很久——DBA 圈子里关于"分区表"的立场其实分裂得很厉害，今天想借这个帖把几种常见做法摊开聊聊。

常见分歧：

1. 分区党：RANGE 按 create_time 月分区，配合分区裁剪，单分区查询从秒级降到毫秒级；归档、删旧数据用 DROP PARTITION 一把梭，运维友好。
2. 反分区党：认为分区只是"换个姿势存数据"，并不解决索引缺失、SQL 写法问题；一旦 WHERE 不带分区键就退化成扫全表，反而比单表还慢；而且 MySQL 的分区表对二级索引、唯一键（必须包含分区键）有约束，业务侧经常踩坑。
3. 拆表党：直接按业务维度做水平拆分（按租户 / 按用户 hash），分库分表框架（ShardingSphere、MyCat、Vitess）成熟，比"伪分布式"的分区表更可控。

我的倾向（供拍砖）：

• 单表 < 5000 万行、有合理索引、慢查询能治理 → 别急着上分区，先把 EXPLAIN、索引、SQL 改写做扎实。
• 单表 5000 万 – 5 亿、有强时间归档诉求（日志、流水、账单）→ 分区表是"性价比最高"的选择，DROP PARTITION 归档是杀手锏。
• 超过 5 亿、且写入持续、需要多租户隔离 → 直接上分库分表，别再纠结分区了。

想听大家在什么场景下怎么选？特别想收两类经验： a) 上分区表后来后悔（或真香）的具体案例，最好带数据； b) 业务方坚持要"分区"但实际是"分库分表"诉求，你是怎么劝的？

先抛砖，等各位。