标签频道
分区表
该标签下的文章、提问与讨论帖。
背景 MySQL 8.0.32,InnoDB,订单流水表 "t_order_flow" 约 2.4 亿行,按 "created_at" 做 RANGE 月分区(约 30 个分区),二级索引 "idx_merchant_time (merch
«结论先行:分区表不是"大表救星",而是一笔用"跨分区查询更慢 + 唯一键受限 + 每月必维护"去换"分区裁剪快 + 删历史秒级"的交易。该不该做,取决于你的读写是否天然按时间切分。下面是一次真实的改造复盘,把收益和代价都摆到明面上算账。»
discussion
数据从千万涨到亿级,历史数据到底该归档、分区、还是冷热分离?
背景 做大数据平台这几年,我遇到的最频繁的架构讨论不是「怎么加索引」,而是「表越来越大,历史数据怎么办」。 一个很典型的场景:订单流水表从 2000 万涨到 1.2 亿行,单表 80GB+,80% 的数据是 3 个月以前的。日常业务查询 9
discussion
单表从 1 亿行到 10 亿行:升配、读写分离、分区、分库分表,你的优先级到底怎么排
背景 做了 10 年 DBA,被业务方问得最多的一个问题就是:"我们的表要爆了,下一步该怎么办?" 每次问这话的时候,团队里通常已经开始在四条路线之间摇摆: 1. 垂直扩容:升配,更大规格的实例(vCPU / 内存 / SSD 升级一档),
discussion
千万级大表到底该不该上分区表?三种路线的取舍
背景:最近带团队做一张 2 亿行的订单流水表治理,业务方一上来就说"先分区吧,分区快"。我犹豫了很久——DBA 圈子里关于"分区表"的立场其实分裂得很厉害,今天想借这个帖把几种常见做法摊开聊聊。 常见分歧: 1) 分区党:RANGE 按 c