mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
1639 字
4 分钟
2026年06月11日 | 当数据表太大撑爆磁盘:在线DDL与分库分表实战
2026-06-11

当数据表太大撑爆磁盘:在线DDL与分库分表实战#

(一开篇就带着一股子妖气) 本宫刚批完折子,就听御膳房的小太监来报,说前朝几位爱卿的数据库——磁盘告急,表大得撑破了肚皮。啧,瞧你们这点出息,后宫三千佳丽本宫都安排得明明白白,你们倒好,一张表就把自己弄得如此狼狈,连本宫都替皇上感到丢人。今儿个,本宫就耐着性子,教你们几招“保命”的手段,都给本宫竖起耳朵听仔细了。

第一桩蠢事:直接上 ALTER TABLE?你是嫌自己死得不够快? 本宫知道,你们最爱干的蠢事,就是在业务高峰期,对着一张千万、上亿行的大表,小手一抖,直接敲个 ALTER TABLE 加字段、改索引。然后呢?然后你就抱着服务器痛哭吧。这操作,堪比在御花园正中央裸奔——不仅锁全表(锁死读写),让所有查询都趴窝等着你,还可能把你的磁盘I/O打得喘不过气,直到超时挂掉。皇上要是看见这场景,高低得赏你一顿廷杖。

正解:请“在线DDL”这位贵妃娘娘出山 对付大表变更,得用温柔刀。在线DDL(Online DDL)就是那个能一边跟你缠绵、一边帮你换衣裳的主儿(比喻请自行体会)。它能在不锁表(或只锁极短时间)的情况下,完成表结构的修改。

  • 避坑第一条:别用你那个老掉牙的数据库客户端傻傻地执行。你得用数据库自带的命令,比如MySQL的 pt-online-schema-change(来自Percona Toolkit)或者 gh-ost(GitHub出品)。它们的原理,简单说就是“金蝉脱壳”:创建一个新结构的表,然后把旧数据一行一行“偷”过去,最后再“闪婚”切换表名。
  • 避坑第二条:执行前,先在测试环境演一百遍!用 pt-online-schema-change 时,务必加上 --chunk-size 控制每次偷的数据量,加上 --max-lag 监控复制延迟(如果你的从库受不了)。别问本宫怎么知道的,问就是前朝某个愣头青,把生产环境的从库搞崩了,在养心殿外跪了一宿。

第二桩蠢事:一张表塞满山珍海味,不知道分家? 有些爱卿更绝,用户表、订单表、日志表、聊天记录……全塞一个库里,一个表里。皇上问一句“上个月用户数多少”,你这边就得好几千次全表扫描,磁盘I/O飙得比汗血宝马还快。这种“一锅炖”的吃相,实在难看。

正解:分库分表,该分家时就分家 当单表数据量超过千万级,且性能已出现瓶颈,就该考虑分了。

  • 垂直拆分:好比把后宫按职能分开。用户相关的放“用户库”,订单相关的放“订单库”。表也一样,把那些很少用到的大字段(比如用户详情、文章正文)拆到另一张表里。这能立竿见影地减小核心表的体积。
  • 水平拆分:这是大活儿,相当于把“后宫佳丽三千”按省份分到不同的别院去。比如,按用户ID取模,把数据分散到多张结构相同的表(user_0, user_1, …)里。这需要你在应用层(你的代码里)或者中间件(比如ShardingSphere)做路由。记住,一旦分了,想跨分片做复杂查询(比如“查所有ID为奇数的订单”),那酸爽,会让你怀疑人生。 所以,拆分键(Sharding Key)的选择,至关重要,必须是你最常用、最核心的查询条件。

本宫手把手教你走个流程(以MySQL为例) 假设你要给一张叫 orders 的大表加个 remark 字段。

  1. 备药:用 pt-online-schema-change。先在从库或测试环境,用 --dry-run 跑一次,看看有没有报错,估算下要跑多久。
  2. 下药:执行正式命令(简化版): pt-online-schema-change --alter "ADD COLUMN remark VARCHAR(255) DEFAULT ''" D=你的库名,t=orders --execute
  3. 盯梢:死死盯住输出的日志。重点关注 Copying 进度和 max lag。如果从库延迟飙升,或者主库负载异常,赶紧按下 Ctrl+C 保命。
  4. 收尾:它完成后会自动切换表名,但你最好手动检查下新表数据是否完整,索引是否正确。然后,再去动应用代码里的表名(如果它用了临时后缀)。

几个要命的小细节,本宫多嘴提醒

  • 磁盘空间:在线DDL需要额外空间来存新表。磁盘都快爆了,你还想玩这个?先把陈年日志清一清,把备份挪个窝吧。
  • 主从延迟:在高并发业务期操作,延迟可能把你拖垮。尽量挑深夜,皇上睡了的时候,偷偷干活。
  • 应用兼容:分库分表后,你的代码里所有 SELECT * FROM orders 都得改成带分片键的查询,或者走中间件。忘了改?恭喜你,收获一堆空结果和诡异bug。
  • 监控!监控!监控! 重要的事说三遍。操作期间,CPU、内存、磁盘I/O、数据库连接数、慢查询数量……所有指标都要瞪大眼睛看着。

最后的碎碎念 治数据如治国,亦如管理后宫。平日里就要勤快点,做好分区、归档(把老数据转存到冷备),别等到天下大乱才想起求神拜佛。本宫今日说的这些,都是保命的底牌。若还有哪个不长记性的,下次数据撑爆磁盘,就自己去向皇上请罪吧,别来烦本宫。

(扇子一收,袅袅退场)

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

2026年06月11日 | 当数据表太大撑爆磁盘:在线DDL与分库分表实战
https://www.yunio.cn/posts/2026-06-11-当数据表太大撑爆磁盘在线ddl与分库分表实战/
作者
媚娘
发布于
2026-06-11
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

目录