标签频道
分区表
该标签下的文章、提问与讨论帖。
背景 我们正在评估一个日均写入10亿+行的埋点日志表（MySQL 8.0.32）的归档方案。当前表规模已达8.2亿行/460GB，按天分区后清理效率从DELETE的47分钟/次降至DROP PARTITION的0.6秒/次（参考文章[102
结论先行 InnoDB 里 "DELETE" 是「标记删除 + 空间回收进 free list」，不是「物理抹掉文件里的字节」。删掉 1.7 亿行后 ".ibd" 文件大小几乎不变，这不是 bug、不是磁盘没刷、更不是数据没删掉——被删行占
背景 MySQL 8.0.32（RDS，32C128G，buffer_pool 96G），交易流水表 "t_txn" 约 2.8 亿行，按 "tenant_id" 做 HASH 分区（64 个分区），二级索引 "idx_tenant_biz
背景 我负责一套 SaaS 多租户系统的核心订单库，MySQL 8.0.32（InnoDB，16C64G，NVMe SSD，"innodb_buffer_pool_size=48G"）。核心表 "t_order" 约 6200 万行、单表含
一、现象与背景：每天凌晨的「清理任务」，把从库拖到 19 秒 先给结论：「按时间过期、过期整块删」的日志/流水表，用 "DELETE" 清理是错的方向；"RANGE 分区 + DROP PARTITION" 才是正解；"分库" 是治「单表太
【背景】 MySQL 8.0.32，InnoDB，生产库一张交易流水表 t_flow 约 5 亿行、单表 140GB，目前是非分区表，唯一键是 (order_no, biz_date) 两个业务字段。业务侧 90% 查询都带 3 个月内的
背景 MySQL 8.0.32，InnoDB，订单流水表 "t_order_flow" 约 2.4 亿行，按 "created_at" 做 RANGE 月分区（约 30 个分区），二级索引 "idx_merchant_time (merch
«结论先行：分区表不是"大表救星"，而是一笔用"跨分区查询更慢 + 唯一键受限 + 每月必维护"去换"分区裁剪快 + 删历史秒级"的交易。该不该做，取决于你的读写是否天然按时间切分。下面是一次真实的改造复盘，把收益和代价都摆到明面上算账。»
背景 做大数据平台这几年，我遇到的最频繁的架构讨论不是「怎么加索引」，而是「表越来越大，历史数据怎么办」。 一个很典型的场景：订单流水表从 2000 万涨到 1.2 亿行，单表 80GB+，80% 的数据是 3 个月以前的。日常业务查询 9
背景 做了 10 年 DBA，被业务方问得最多的一个问题就是："我们的表要爆了，下一步该怎么办？" 每次问这话的时候，团队里通常已经开始在四条路线之间摇摆： 1. 垂直扩容：升配，更大规格的实例（vCPU / 内存 / SSD 升级一档），
背景：最近带团队做一张 2 亿行的订单流水表治理，业务方一上来就说"先分区吧，分区快"。我犹豫了很久——DBA 圈子里关于"分区表"的立场其实分裂得很厉害，今天想借这个帖把几种常见做法摊开聊聊。 常见分歧： 1) 分区党：RANGE 按 c
文
标题
摘要