1. 存储分层不是一个新概念但数据库场景下值得重新审视先聊点背景。很多人一听到“存储分层”第一反应是“这不就是缓存吗”“把热数据放SSD、冷数据放HDD或者归档存储听着很常规”。但真正在数据库环境里落地过的人都知道事情没那么简单。热数据和冷数据的边界怎么划数据从热到冷、从冷到热的流转由谁触发业务高峰期做数据迁移会不会把IO打满这些坑不踩一遍光靠看架构图是体会不到的。我这次做的项目就是一套典型的“数据库存储分层架构”热数据跑在SSD上冷数据归档到低速大容量存储同时把整个过程中的性能指标拉出来做了对比。标题里提到的“配置操作及性能对比分析”是核心但我觉得更有价值的部分是整个架构从设计到落地的决策链路——为什么这么分、分完之后怎么保证查询不翻车、数据迁移怎么做才不影响线上。这篇文章适合谁看两类人。一类是刚接手公司数据库运维、被“数据量涨得太快SSD快满了”逼着做冷热分离的同学另一类是自己在做架构设计想评估“存储分层到底能带来多大收益”的开发者。我不会只给结论会把操作步骤、配置细节、实测数据、踩过的坑都摊开来讲尽量做到让看完的人能直接照着搭一套出来。先声明一下下面的操作和思路基于我自己的测试环境搭建的是MySQL 8.0集群操作系统用的CentOS 7.9SSD和归档存储都是通过逻辑卷管理LVM挂载的。生产环境的设计思路可以复用但具体参数要根据你的业务做调整。2. 冷热数据的判定逻辑别拍脑袋先看数据特征2.1 “热”和“冷”的本质是访问频率不是数据新旧很多人有个误区觉得“最近写入的数据就是热数据很久以前写入的就是冷数据”。这个说法在大部分场景下成立但并不绝对。比如一个订单系统今天产生的订单肯定频繁被访问算热数据三年前的订单基本没人查算冷数据。但换到审计系统或合规平台可能查的就是半年前甚至两年前的记录这时候时间维度的判断就失效了。所以设计存储分层的第一步不是买盘、不是改配置而是先定清楚业务里什么样的数据才算“热”。我自己的做法是先摸清数据库的访问特征直接看MySQL的慢查询日志和performance_schema里的表访问统计重点盯两个指标表的读请求频率和单次查询扫描的行数。比如你有一张日志表每天增长几百万行但业务上只会查最近7天的数据那这张表里7天以前的数据就是天然的冷数据。又比如一张用户表全表只有几十万行但每次登录都要查那不管它存在了多久都应该是热数据。2.2 用分区表做冷热隔离是性价比最高的起点要实现真正的分层存储前提是“数据能按冷热拆开”。MySQL里最优雅的做法是使用分区表按时间或者按某个业务键做Range分区然后把不同分区放到不同的物理存储上。当然MySQL原生的分区表在8.0之前不支持将不同分区直接放到不同磁盘上但我们可以通过“分区表 数据目录软链接”或者“独立表空间 迁移”的方式实现类似效果。我这次采用的方式是按月份做Range分区每个月一个分区。同时每个分区对应一个独立表空间文件innodb_file_per_table默认开启这样每个分区的数据文件就是独立的 .ibd 文件方便我后续针对“冷分区文件”单独做迁移。建表语句大致长这样CREATE TABLE order_record ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL, user_id bigint NOT NULL, amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0, create_time datetime NOT NULL, PRIMARY KEY (id,create_time) ) ENGINEInnoDB PARTITION BY RANGE (TO_DAYS(create_time)) ( PARTITION p202301 VALUES LESS THAN (TO_DAYS(2023-02-01)), PARTITION p202302 VALUES LESS THAN (TO_DAYS(2023-03-01)), PARTITION p202303 VALUES LESS THAN (TO_DAYS(2023-04-01)), PARTITION p202304 VALUES LESS THAN (TO_DAYS(2023-05-01)), PARTITION p_future VALUES LESS THAN MAXVALUE );这里有几个关键点主键必须包含分区键否则MySQL会报错“PRIMARY KEY must include all columns in the tables partitioning function”。如果你不想改主键可以考虑使用二级分区或者直接把分区表设计调整成“分区键作为联合主键的一部分”。p_future分区一定要保留否则到了月底下个月的数据就插不进去了到时候再加分区会锁表。TO_DAYS()函数在大数据量下性能尚可但如果分区键是时间戳字段建议直接用整数类型避免每次插入都做函数计算。2.3 数据归档策略谁来决定数据“变冷”分区建好了接下来要回答的问题是“什么时候把某个分区从SSD挪到归档存储”。我的策略是提前定一个规则数据超过6个月自动进入归档流程。为什么不选3个月因为我们的业务查询窗口一般在半年以内超过半年的数据被业务直接查询的概率极低。而且定6个月也留足了缓冲即便有跨半年的报表查询也只是小概率事件不会频繁触发跨存储访问。归档流程用脚本定时任务实现核心动作分三步把超过6个月的分区从分区表中拆分出来转成独立表将独立表的数据文件迁移到归档存储在原库中重建一个同结构的空表可选用于应急查询。具体SQL和shell脚本我会在后面的章节细说这里先记住一个大原则迁移冷数据的操作必须在业务低峰期执行并且要控制迁移速度绝对不能一把梭直接把几个G的文件瞬间拷过去。后续测试对比时你会发现存储迁移对IO的影响远比你想象的大。3. 硬件选型与文件系统布局SSD、归档盘的分工与挂载细节3.1 SSD选SSD先分清“耐用型”和“性能型”SSD的坑在数据库场景下格外明显。很多人在选型时只看顺序读写速度忽略了另一个关键指标寿命DWPD每日全盘写入次数。数据库的在线日志redo log、binlog写入非常频繁属于典型的“持续写入”负载。如果选了一款DWPD只有0.3的消费级SSD大概率半年内就会出现写放大导致的性能衰减甚至掉盘。我这次测试环境用的SSD是企业级SATA SSDDWPD在1左右虽然不是顶级但足够模拟真实业务。生产环境建议按自己的写入量估算保守一点选DWPD≥0.8的型号。另外SSD的容量规划也要留足冗余。别把数据文件塞到硬盘的90%以上SSD在接近满盘的时候垃圾回收会频繁触发读写延迟会明显上升。我习惯是数据盘使用率控制在70%以内。3.2 LVM的条带化与归档盘的挂载策略为了让SSD性能尽量发挥出来我用LVM做了逻辑卷配置为条带化striped模式相当于把多块物理SSD组成一个RAID 0的逻辑卷提升读写吞吐。生产环境如果是关键业务建议做成RAID 1或者RAID 10虽然容量减半但可靠性优先。创建条带化逻辑卷的参考命令pvcreate /dev/sdb /dev/sdc vgcreate vg_ssd /dev/sdb /dev/sdc lvcreate -L 500G -n lv_ssd -i 2 -I 64 vg_ssd mkfs.xfs /dev/vg_ssd/lv_ssd mkdir /data/ssd mount /dev/vg_ssd/lv_ssd /data/ssd上面的-i 2表示使用两块盘做条带-I 64表示条带大小是64KB这个值不是拍脑袋定的而是参考了MySQL InnoDB的默认页大小16KB和文件系统块大小4KB之间的常见组合。条带大小设置得太小会导致IO碎片化严重太大会让单次IO集中在某一两块盘上64KB对中等负载来说比较均衡。归档存储这边我用的是一块7200转的机械硬盘格式化成XFS后挂载到/data/archive。归档存储追求的是容量和成本对IOPS要求不高但同样建议用独立挂载点避免和系统盘互相干扰。挂载后在/etc/fstab里加上对应的配置重启不丢挂载/dev/vg_ssd/lv_ssd /data/ssd xfs defaults,noatime 0 0 /dev/sdd1 /data/archive xfs defaults,noatime 0 0加noatime是避免每次读文件都更新访问时间戳减少无谓的写IO。3.3 MySQL数据目录的规划把冷热数据目录分开为了后续迁移方便MySQL的数据目录我做了拆分。SSD上放MySQL的主数据目录归档盘上放一个archive_data目录。实际的迁移动作是通过MySQL的ALTER TABLE ... DISCARD TABLESPACE和IMPORT TABLESPACE来完成的而不是直接复制文件。具体流程大概是在归档库上建一张同结构的表执行ALTER TABLE ... DISCARD TABLESPACE把归档库上刚建的表空间文件删除把源库的order_record中对应分区的.ibd文件复制到归档库的数据目录下网络传输或本地复制执行ALTER TABLE ... IMPORT TABLESPACE让归档库加载这个表空间。这样做的好处是归档库和源库是物理隔离的归档库只读不影响源库性能。如果后续需要查询归档数据直接连归档库查就行最多就是慢一点但不会拖垮SSD上的在线业务。4. 核心操作实录将冷分区从SSD迁移到归档存储4.1 把目标分区拆成独立表先用一条SQL将分区转换为独立表。MySQL支持ALTER TABLE ... REORGANIZE PARTITION或ALTER TABLE ... EXCHANGE PARTITION我更喜欢用EXCHANGE PARTITION因为它的语义更明确操作速度也很快。比如我要把p202301这个分区2023年1月的数据转成独立表order_record_202301ALTER TABLE order_record EXCHANGE PARTITION p202301 WITH TABLE order_record_202301;执行前需要先手动创建一张和主表结构完全一样的表order_record_202301并且这张表不能有外部外键依赖。交换后原来p202301分区就空了数据都在order_record_202301里。这个操作的元数据变更非常快因为它不涉及物理数据移动只是修改了数据字典的表分区映射关系实测在数据量几百万行时也是毫秒级完成。4.2 物理迁移.ibd文件到归档存储表独立之后她对应的表空间文件就是/data/ssd/mysql/order_record_202301.ibd。我用INNODB_FILE_PER_TABLE的模式每个表单独一个文件方便直接拷贝。迁移到归档存储的方式有两种方式一直接拷贝文件到归档盘同时保留源库文件备份。适合冷数据容量不大、归档盘和SSD在同一台机器的情况。方式二通过mysqldump导入导出。适合跨机器迁移因为逻辑备份不依赖物理文件路径更灵活但速度慢。我测试环境用的方式一先创建归档目录再用cp拷贝mkdir -p /data/archive/mysql_archive cp /data/ssd/mysql/order_record_202301.ibd /data/archive/mysql_archive/拷贝完成后源库中这张表仍然可以查询只是如果继续写入会导致文件不一致所以我们在迁移过程中需要把表锁住或者干脆先停止对这个表的写入。我采取的办法是业务低峰期执行迁移迁移窗口内对这张表只读。4.3 在源库中删除旧表并保留归档副本确认数据文件已经成功归档后在源库中删除这张独立表释放SSD空间DROP TABLE order_record_202301;注意这里删除前必须确认归档文件已经完整拷贝并且最好做一个文件哈希校验比如用md5sum比对源文件和归档文件的MD5值防止文件拷贝损坏。这一步做完SSD上的空间就释放了冷数据已经从SSD上逻辑消失但归档存储上保留了完整的数据文件。如果要查询归档数据单独连接归档恢复环境即可。4.4 自动化的定时任务配置上面的步骤手动执行一次没问题但冷数据归档是一个持续性任务。我写了一个Shell脚本通过crontab每周日凌晨2点执行一次。脚本的主要逻辑是找出当前日期往前推6个月的分区名执行ALTER TABLE ... EXCHANGE PARTITION拆表拷贝.ibd文件到归档目录校验MD5删除源表记录日志。脚本节选如下#!/bin/bash DB_USERroot DB_PASSyourpass DB_NAMEtestdb TABLEorder_record ARCHIVE_DIR/data/archive/mysql_archive DATA_DIR/data/ssd/mysql EXPIRE_MONTH$(date -d 6 months ago %Y%m) PART_NAMEp${EXPIRE_MONTH} ARCHIVE_TABLE${TABLE}_${EXPIRE_MONTH} # 1. create empty table with same structure mysql -u$DB_USER -p$DB_PASS $DB_NAME -e CREATE TABLE $ARCHIVE_TABLE LIKE $TABLE; # 2. exchange partition mysql -u$DB_USER -p$DB_PASS $DB_NAME -e ALTER TABLE $TABLE EXCHANGE PARTITION $PART_NAME WITH TABLE $ARCHIVE_TABLE; # 3. copy ibd file cp $DATA_DIR/$ARCHIVE_TABLE.ibd $ARCHIVE_DIR/ # 4. verify md5 SRC_MD5$(md5sum $DATA_DIR/$ARCHIVE_TABLE.ibd | awk {print $1}) DST_MD5$(md5sum $ARCHIVE_DIR/$ARCHIVE_TABLE.ibd | awk {print $1}) if [ $SRC_MD5 $DST_MD5 ]; then mysql -u$DB_USER -p$DB_PASS $DB_NAME -e DROP TABLE $ARCHIVE_TABLE; echo $(date) - $ARCHIVE_TABLE archived successfully /var/log/archive_cron.log else echo $(date) - $ARCHIVE_TABLE md5 mismatch, keep source table /var/log/archive_cron.log fi这个脚本在真实运行时还需要考虑锁表、错误处理、并发控制等细节但基础框架已经能跑通。我的原则是先把简单能用的逻辑跑起来再逐步完善。生产环境建议用类似PT-Online-Schema-Change工具或者通过MySQL的在线DDL特性来做降低对业务的影响。5. 对比测试设计用同一套查询对比SSD与归档存储的性能差距5.1 测试数据与查询样式的准备性能对比是这次项目的重头戏。为了让测试结果公平我准备了同一张表的两份数据一份完整放在SSD上一份完整放在归档存储上。为了模拟真实场景测试数据集共约300万行建立了两个索引idx_create_time和idx_user_id。对比语句设计了三类典型场景点查Point QuerySELECT * FROM order_record WHERE user_id 12345;范围查询Range QuerySELECT * FROM order_record WHERE create_time BETWEEN 2023-01-01 00:00:00 AND 2023-01-31 23:59:59;聚合查询Aggregation QuerySELECT COUNT(*), SUM(amount) FROM order_record WHERE create_time 2023-01-01;考虑到机械硬盘的顺序读性能其实还可以但随机读性能极差因此点查和范围查询最能体现SSD和归档盘的差异。聚合查询如果走索引扫描在归档盘上也会慢得多尤其是需要回表的情况下。5.2 测试方法和工具我用了两种方式来测量查询性能MySQL自带的PROFILING或performance_schema得到精确的耗时sysbench 的oltp_read_only压测模式用来测试并发场景下的整体QPS和平均延迟。sysbench压测命令示例sysbench /usr/share/sysbench/oltp_read_only.lua \ --mysql-host127.0.0.1 \ --mysql-userroot \ --mysql-passwordyourpass \ --mysql-dbtestdb \ --tables1 \ --table-size3000000 \ --threads16 \ --time60 \ --report-interval5 \ run这里需要注意sysbench默认会自己建表和造数据但我们是已经有一张order_record表了所以可以跳过prepare阶段直接用run指令跑已经存在的表或者按它的格式把表结构调整成sysbench认识的类型。为了测试公平我建议针对自己建的数据表写一个Lua脚本或者直接用SQL脚本循环执行来测单条语句耗时。5.3 单条查询性能实测数据我分别对SSD和归档盘上的同一张表执行了上述三类查询每种查询执行10次取中间值去掉最高最低结果如下查询类型SSD耗时(ms)归档盘耗时(ms)性能差距点查2.838.6约14倍范围查询6.2142.5约23倍聚合查询11.4368.2约32倍这个结果符合预期机械硬盘的随机读性能是硬伤范围查询和聚合查询在缺少覆盖索引时需要大量随机读数据页所以差距会进一步拉大。而SSD的随机读能力远强于机械盘即使数据量很大点查也能保持在几毫秒级别。归档盘上的聚合查询慢到接近400毫秒对在线业务来说肯定是不可接受的但如果你只是做离线报表或者非高峰期的数据分析这个延迟完全可以忍受。这也是冷热分离的意义所在——把慢查询限制在冷数据上不让它影响主业务。5.4 并发压力测试QPS与延迟变化再来看并发场景。我用sysbench跑60秒的只读压测16个并发线程。结果如下存储类型平均QPS平均延迟(ms)P99延迟(ms)SSD72002.24.8归档盘86018.642.3从 QPS 看差距大约是8倍但延迟的P99差距更明显归档盘在并发下有接近42ms的抖动而SSD则非常平稳。实际业务中如果查询并发一旦高起来机械盘很容易变成瓶颈导致数据库连接堆积甚至影响其他正常查询。6. 性能差异背后的原理随机读写、IO队列与缓存机制6.1 机械盘的随机IO为何慢得离谱很多人只知道“机械盘慢”但说不清慢在哪。机械硬盘的读写过程包含磁头寻道、盘片旋转等物理动作每次随机访问都要等待磁头移动到目标磁道这个“寻道时间”通常在几毫秒到十几毫秒。而数据库的B树索引天生就是随机访问模式的即使你只查一条记录也可能需要沿着索引树的层级一路跳转读取多个数据页。每一页读取都是一次随机IO累积下来就是几十毫秒的延迟。SSD没有机械结构数据存储在闪存颗粒中通过控制器直接访问纳秒级就能定位到目标位置所以随机读性能和顺序读性能差距不大。这就是为什么数据库这种随机读密集的应用SSD能带来十几倍甚至几十倍的性能提升。6.2 InnoDB缓冲池对性能测试的干扰在做性能对比时有个隐形的干扰项InnoDB缓冲池Buffer Pool。MySQL默认会将数据页缓存在内存里同一份数据如果已经被读入内存第二次查询就不会触及物理磁盘导致测试结果失真。我为了测真实的磁盘性能在每轮测试前都执行了以下操作清空MySQL的缓冲池缓存SET GLOBAL innodb_buffer_pool_size 0;但注意innodb_buffer_pool_size在MySQL 8.0里是只读参数不能在线设为0。更稳妥的办法是用innodb_buffer_pool_dump_now和innodb_buffer_pool_load_now配合或者干脆重启MySQL这样Buffer Pool是空的。测试环境我直接重启了MySQL确保冷缓存状态下测试才能反映出“从磁盘读数据”的真实延迟。如果你的测试环境不能重启还可以用TABLE命令预热或冷表的方式但最严谨的方式还是重启。6.3 为什么冷数据盘上的“覆盖索引”能救一手虽然归档盘慢但也不是没有优化手段。一个很常见的手段是在归档表上创建覆盖索引尽量让查询在索引叶中返回所有需要的字段避免回表。举个例子如果我们的聚合查询是SELECT COUNT(*), SUM(amount) FROM order_record WHERE create_time 2023-01-01在create_time上建索引后InnoDB会扫描二级索引虽然还是随机读但至少读取的是更紧凑的索引页比回表读整行要快很多。如果你把amount也放到联合索引(create_time, amount)里那么SUM(amount)可以直接从索引里获得完全避免回表这种优化对归档存储的查询收益非常大。我做过一个对比在同一张归档表上不建覆盖索引执行聚合查询耗时368ms建了(create_time, amount)覆盖索引后降到约120ms。虽然还是比SSD慢但至少能接受。7. 数据一致性保障迁移过程中的锁、校验与回滚方案7.1 迁移过程中如何避免数据不一致冷数据迁移最怕的不是慢而是数据不一致。我在最初测试时遇到过一个问题用EXCHANGE PARTITION拆表后如果业务端还有写操作往这个分区插入数据会导致表在拆分过程中丢失部分数据。解决思路有两个迁移窗口内锁定目标表对业务侧透明使用LOCK TABLES ... WRITE等迁移完成后再解锁。缺点是可能导致短时写入阻塞。引入一台只读归档库源库在迁移过程中不需要停写但需要额外做一次增量同步逻辑复杂。我最终选择了第一种方案因为我们是低峰期操作锁几秒到几十秒是可以接受的。锁表语句LOCK TABLES order_record WRITE; -- 执行拆表、拷贝、删除 UNLOCK TABLES;注意LOCK TABLES本身会触发隐式提交需要确保事务已经提交后再执行。7.2 文件完整性校验与常见坑拷贝.ibd文件时一个常见坑是MySQL 正在运行期间虽然表已经被拆出来了但如果还有查询没有释放文件句柄直接拷贝可能导致文件内容不一致。我一般会等几秒确认没有新连接访问这个表后再执行拷贝。文件拷完后除了比对MD5还要注意文件权限。MySQL的datadir文件所有者必须是mysql:mysql如果拷贝到归档目录后所有者不对后面需要用chown修正chown mysql:mysql /data/archive/mysql_archive/order_record_202301.ibd另外如果归档盘的文件系统不支持某些特性比如稀疏文件、大文件拷贝也可能会报错。建议归档盘用XFS或ext4不建议用FAT32这类不支持超过4GB单文件的老格式。7.3 若迁移失败如何快速回滚任何迁移方案都要有回滚预案。我的做法是在迁移前保留源库的独立表不立刻删除直到归档文件校验通过后才启动删除。如果迁移中途失败源表还在可以直接将EXCHANGE PARTITION反向操作把独立表的数据重新交换回分区表恢复原状。反向操作ALTER TABLE order_record EXCHANGE PARTITION p202301 WITH TABLE order_record_202301;如果已经执行了DROP TABLE order_record_202301那就只能通过归档存储恢复或者使用备份文件了。所以我的建议是删除源表之前至少保留24小时确认业务无任何异常再清理。稳妥大于省事。8. 优化与扩展从“手动归档”到“半自动分层”的进阶思路8.1 用MySQL事件调度器定期重命名分区前面的自动化脚本用的是crontab但MySQL本身也支持“事件调度器”Event Scheduler可以定期执行SQL。如果你倾向于尽量少碰Shell可以用事件来实现定期创建新分区和归档旧分区。示例每天创建下个月的分区CREATE EVENT auto_add_partition ON SCHEDULE EVERY 1 DAY DO BEGIN -- 动态拼接SQL添加分区 SET next_month DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 1 MONTH), %Y-%m-01); SET sql CONCAT(ALTER TABLE order_record ADD PARTITION (PARTITION p, DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 1 MONTH), %Y%m), VALUES LESS THAN (TO_DAYS(\, next_month, \)))); PREPARE stmt FROM sql; EXECUTE stmt; END;注意事件调度器默认可能是关闭的需要SET GLOBAL event_scheduler ON;。这种方式适合自动化程度要求高的场景但SQL动态拼接的维护成本略高生产环境要做好充分测试。8.2 从“物理分层”到“逻辑分层”引入归档库与数据生命周期管理当数据量大到单机物理存储完全扛不住的时候单纯的SSD归档盘已经不够了。这时候可以考虑引入独立的归档数据库节点专门存放冷数据。通过MySQL的主从复制或者CLONE插件把冷数据同步到归档节点然后在主库上删除旧分区实现逻辑上的冷热分离。这种架构的好处是主库只保留热数据索引体积更小查询更快归档库独立部署可以跑批量任务不影响主库性能支持把归档库迁移到更便宜的存储服务器比如云上的低频访问存储。缺点是架构复杂度增加数据一致性需要靠binlog或数据同步工具来保证。我们之前被热搜词里反复提到“数据库同步软件”“数据库同步工具”其实正是这类架构落地时不可或缺的组件。8.3 分层后的监控与告警存储分层做完并不意味着万事大吉。我强烈建议对冷热存储分别配置监控指标至少包括SSD的使用率超过80%告警归档盘的写入速率与错误率SMART信息冷数据迁移任务的执行状态成功/失败/耗时归档查询的延迟和失败率我用Prometheus node_exporter 自定义exporter监控磁盘和MySQL状态通过Grafana展示。迁移脚本每次执行完都把成功/失败状态写入日志再用脚本解析日志推送告警到钉钉或邮件。这样任何一次归档异常都能第一时间发现。9. 实测总结与个人心得这套分层架构的收益与成本最后说点实际的。这个分层架构跑通之后收获是立竿见影的SSD空间占用下降了62%热数据查询性能保持稳定归档数据查询按需连接归档库影响可控。整个迁移过程中遇到过几次小问题但都在预案范围内解决了。我个人最大的感受是存储分层本身不复杂复杂的是“判定冷热”和“保证一致性”这两件事。定错了冷热边界可能把本该热的数据归档掉导致线上查询变慢迁移过程中稍微疏忽就可能造成数据损坏或丢失。所以无论方案听起来多完美都要在测试环境反复演练尤其是回滚流程一定要跑通。如果你也准备做数据库存储分层建议从一张具体的大表开始不要一上来就全库迁移。先把流程跑顺观测一段时间的查询延迟、空间变化、迁移耗时再逐步推广到其他表。毕竟数据库架构调整稳永远比快重要。 数据库存储分层实战：MySQL冷热数据迁移与性能对比分析
1. 存储分层不是一个新概念但数据库场景下值得重新审视先聊点背景。很多人一听到“存储分层”第一反应是“这不就是缓存吗”“把热数据放SSD、冷数据放HDD或者归档存储听着很常规”。但真正在数据库环境里落地过的人都知道事情没那么简单。热数据和冷数据的边界怎么划数据从热到冷、从冷到热的流转由谁触发业务高峰期做数据迁移会不会把IO打满这些坑不踩一遍光靠看架构图是体会不到的。我这次做的项目就是一套典型的“数据库存储分层架构”热数据跑在SSD上冷数据归档到低速大容量存储同时把整个过程中的性能指标拉出来做了对比。标题里提到的“配置操作及性能对比分析”是核心但我觉得更有价值的部分是整个架构从设计到落地的决策链路——为什么这么分、分完之后怎么保证查询不翻车、数据迁移怎么做才不影响线上。这篇文章适合谁看两类人。一类是刚接手公司数据库运维、被“数据量涨得太快SSD快满了”逼着做冷热分离的同学另一类是自己在做架构设计想评估“存储分层到底能带来多大收益”的开发者。我不会只给结论会把操作步骤、配置细节、实测数据、踩过的坑都摊开来讲尽量做到让看完的人能直接照着搭一套出来。先声明一下下面的操作和思路基于我自己的测试环境搭建的是MySQL 8.0集群操作系统用的CentOS 7.9SSD和归档存储都是通过逻辑卷管理LVM挂载的。生产环境的设计思路可以复用但具体参数要根据你的业务做调整。2. 冷热数据的判定逻辑别拍脑袋先看数据特征2.1 “热”和“冷”的本质是访问频率不是数据新旧很多人有个误区觉得“最近写入的数据就是热数据很久以前写入的就是冷数据”。这个说法在大部分场景下成立但并不绝对。比如一个订单系统今天产生的订单肯定频繁被访问算热数据三年前的订单基本没人查算冷数据。但换到审计系统或合规平台可能查的就是半年前甚至两年前的记录这时候时间维度的判断就失效了。所以设计存储分层的第一步不是买盘、不是改配置而是先定清楚业务里什么样的数据才算“热”。我自己的做法是先摸清数据库的访问特征直接看MySQL的慢查询日志和performance_schema里的表访问统计重点盯两个指标表的读请求频率和单次查询扫描的行数。比如你有一张日志表每天增长几百万行但业务上只会查最近7天的数据那这张表里7天以前的数据就是天然的冷数据。又比如一张用户表全表只有几十万行但每次登录都要查那不管它存在了多久都应该是热数据。2.2 用分区表做冷热隔离是性价比最高的起点要实现真正的分层存储前提是“数据能按冷热拆开”。MySQL里最优雅的做法是使用分区表按时间或者按某个业务键做Range分区然后把不同分区放到不同的物理存储上。当然MySQL原生的分区表在8.0之前不支持将不同分区直接放到不同磁盘上但我们可以通过“分区表 数据目录软链接”或者“独立表空间 迁移”的方式实现类似效果。我这次采用的方式是按月份做Range分区每个月一个分区。同时每个分区对应一个独立表空间文件innodb_file_per_table默认开启这样每个分区的数据文件就是独立的 .ibd 文件方便我后续针对“冷分区文件”单独做迁移。建表语句大致长这样CREATE TABLE order_record ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL, user_id bigint NOT NULL, amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0, create_time datetime NOT NULL, PRIMARY KEY (id,create_time) ) ENGINEInnoDB PARTITION BY RANGE (TO_DAYS(create_time)) ( PARTITION p202301 VALUES LESS THAN (TO_DAYS(2023-02-01)), PARTITION p202302 VALUES LESS THAN (TO_DAYS(2023-03-01)), PARTITION p202303 VALUES LESS THAN (TO_DAYS(2023-04-01)), PARTITION p202304 VALUES LESS THAN (TO_DAYS(2023-05-01)), PARTITION p_future VALUES LESS THAN MAXVALUE );这里有几个关键点主键必须包含分区键否则MySQL会报错“PRIMARY KEY must include all columns in the tables partitioning function”。如果你不想改主键可以考虑使用二级分区或者直接把分区表设计调整成“分区键作为联合主键的一部分”。p_future分区一定要保留否则到了月底下个月的数据就插不进去了到时候再加分区会锁表。TO_DAYS()函数在大数据量下性能尚可但如果分区键是时间戳字段建议直接用整数类型避免每次插入都做函数计算。2.3 数据归档策略谁来决定数据“变冷”分区建好了接下来要回答的问题是“什么时候把某个分区从SSD挪到归档存储”。我的策略是提前定一个规则数据超过6个月自动进入归档流程。为什么不选3个月因为我们的业务查询窗口一般在半年以内超过半年的数据被业务直接查询的概率极低。而且定6个月也留足了缓冲即便有跨半年的报表查询也只是小概率事件不会频繁触发跨存储访问。归档流程用脚本定时任务实现核心动作分三步把超过6个月的分区从分区表中拆分出来转成独立表将独立表的数据文件迁移到归档存储在原库中重建一个同结构的空表可选用于应急查询。具体SQL和shell脚本我会在后面的章节细说这里先记住一个大原则迁移冷数据的操作必须在业务低峰期执行并且要控制迁移速度绝对不能一把梭直接把几个G的文件瞬间拷过去。后续测试对比时你会发现存储迁移对IO的影响远比你想象的大。3. 硬件选型与文件系统布局SSD、归档盘的分工与挂载细节3.1 SSD选SSD先分清“耐用型”和“性能型”SSD的坑在数据库场景下格外明显。很多人在选型时只看顺序读写速度忽略了另一个关键指标寿命DWPD每日全盘写入次数。数据库的在线日志redo log、binlog写入非常频繁属于典型的“持续写入”负载。如果选了一款DWPD只有0.3的消费级SSD大概率半年内就会出现写放大导致的性能衰减甚至掉盘。我这次测试环境用的SSD是企业级SATA SSDDWPD在1左右虽然不是顶级但足够模拟真实业务。生产环境建议按自己的写入量估算保守一点选DWPD≥0.8的型号。另外SSD的容量规划也要留足冗余。别把数据文件塞到硬盘的90%以上SSD在接近满盘的时候垃圾回收会频繁触发读写延迟会明显上升。我习惯是数据盘使用率控制在70%以内。3.2 LVM的条带化与归档盘的挂载策略为了让SSD性能尽量发挥出来我用LVM做了逻辑卷配置为条带化striped模式相当于把多块物理SSD组成一个RAID 0的逻辑卷提升读写吞吐。生产环境如果是关键业务建议做成RAID 1或者RAID 10虽然容量减半但可靠性优先。创建条带化逻辑卷的参考命令pvcreate /dev/sdb /dev/sdc vgcreate vg_ssd /dev/sdb /dev/sdc lvcreate -L 500G -n lv_ssd -i 2 -I 64 vg_ssd mkfs.xfs /dev/vg_ssd/lv_ssd mkdir /data/ssd mount /dev/vg_ssd/lv_ssd /data/ssd上面的-i 2表示使用两块盘做条带-I 64表示条带大小是64KB这个值不是拍脑袋定的而是参考了MySQL InnoDB的默认页大小16KB和文件系统块大小4KB之间的常见组合。条带大小设置得太小会导致IO碎片化严重太大会让单次IO集中在某一两块盘上64KB对中等负载来说比较均衡。归档存储这边我用的是一块7200转的机械硬盘格式化成XFS后挂载到/data/archive。归档存储追求的是容量和成本对IOPS要求不高但同样建议用独立挂载点避免和系统盘互相干扰。挂载后在/etc/fstab里加上对应的配置重启不丢挂载/dev/vg_ssd/lv_ssd /data/ssd xfs defaults,noatime 0 0 /dev/sdd1 /data/archive xfs defaults,noatime 0 0加noatime是避免每次读文件都更新访问时间戳减少无谓的写IO。3.3 MySQL数据目录的规划把冷热数据目录分开为了后续迁移方便MySQL的数据目录我做了拆分。SSD上放MySQL的主数据目录归档盘上放一个archive_data目录。实际的迁移动作是通过MySQL的ALTER TABLE ... DISCARD TABLESPACE和IMPORT TABLESPACE来完成的而不是直接复制文件。具体流程大概是在归档库上建一张同结构的表执行ALTER TABLE ... DISCARD TABLESPACE把归档库上刚建的表空间文件删除把源库的order_record中对应分区的.ibd文件复制到归档库的数据目录下网络传输或本地复制执行ALTER TABLE ... IMPORT TABLESPACE让归档库加载这个表空间。这样做的好处是归档库和源库是物理隔离的归档库只读不影响源库性能。如果后续需要查询归档数据直接连归档库查就行最多就是慢一点但不会拖垮SSD上的在线业务。4. 核心操作实录将冷分区从SSD迁移到归档存储4.1 把目标分区拆成独立表先用一条SQL将分区转换为独立表。MySQL支持ALTER TABLE ... REORGANIZE PARTITION或ALTER TABLE ... EXCHANGE PARTITION我更喜欢用EXCHANGE PARTITION因为它的语义更明确操作速度也很快。比如我要把p202301这个分区2023年1月的数据转成独立表order_record_202301ALTER TABLE order_record EXCHANGE PARTITION p202301 WITH TABLE order_record_202301;执行前需要先手动创建一张和主表结构完全一样的表order_record_202301并且这张表不能有外部外键依赖。交换后原来p202301分区就空了数据都在order_record_202301里。这个操作的元数据变更非常快因为它不涉及物理数据移动只是修改了数据字典的表分区映射关系实测在数据量几百万行时也是毫秒级完成。4.2 物理迁移.ibd文件到归档存储表独立之后她对应的表空间文件就是/data/ssd/mysql/order_record_202301.ibd。我用INNODB_FILE_PER_TABLE的模式每个表单独一个文件方便直接拷贝。迁移到归档存储的方式有两种方式一直接拷贝文件到归档盘同时保留源库文件备份。适合冷数据容量不大、归档盘和SSD在同一台机器的情况。方式二通过mysqldump导入导出。适合跨机器迁移因为逻辑备份不依赖物理文件路径更灵活但速度慢。我测试环境用的方式一先创建归档目录再用cp拷贝mkdir -p /data/archive/mysql_archive cp /data/ssd/mysql/order_record_202301.ibd /data/archive/mysql_archive/拷贝完成后源库中这张表仍然可以查询只是如果继续写入会导致文件不一致所以我们在迁移过程中需要把表锁住或者干脆先停止对这个表的写入。我采取的办法是业务低峰期执行迁移迁移窗口内对这张表只读。4.3 在源库中删除旧表并保留归档副本确认数据文件已经成功归档后在源库中删除这张独立表释放SSD空间DROP TABLE order_record_202301;注意这里删除前必须确认归档文件已经完整拷贝并且最好做一个文件哈希校验比如用md5sum比对源文件和归档文件的MD5值防止文件拷贝损坏。这一步做完SSD上的空间就释放了冷数据已经从SSD上逻辑消失但归档存储上保留了完整的数据文件。如果要查询归档数据单独连接归档恢复环境即可。4.4 自动化的定时任务配置上面的步骤手动执行一次没问题但冷数据归档是一个持续性任务。我写了一个Shell脚本通过crontab每周日凌晨2点执行一次。脚本的主要逻辑是找出当前日期往前推6个月的分区名执行ALTER TABLE ... EXCHANGE PARTITION拆表拷贝.ibd文件到归档目录校验MD5删除源表记录日志。脚本节选如下#!/bin/bash DB_USERroot DB_PASSyourpass DB_NAMEtestdb TABLEorder_record ARCHIVE_DIR/data/archive/mysql_archive DATA_DIR/data/ssd/mysql EXPIRE_MONTH$(date -d 6 months ago %Y%m) PART_NAMEp${EXPIRE_MONTH} ARCHIVE_TABLE${TABLE}_${EXPIRE_MONTH} # 1. create empty table with same structure mysql -u$DB_USER -p$DB_PASS $DB_NAME -e CREATE TABLE $ARCHIVE_TABLE LIKE $TABLE; # 2. exchange partition mysql -u$DB_USER -p$DB_PASS $DB_NAME -e ALTER TABLE $TABLE EXCHANGE PARTITION $PART_NAME WITH TABLE $ARCHIVE_TABLE; # 3. copy ibd file cp $DATA_DIR/$ARCHIVE_TABLE.ibd $ARCHIVE_DIR/ # 4. verify md5 SRC_MD5$(md5sum $DATA_DIR/$ARCHIVE_TABLE.ibd | awk {print $1}) DST_MD5$(md5sum $ARCHIVE_DIR/$ARCHIVE_TABLE.ibd | awk {print $1}) if [ $SRC_MD5 $DST_MD5 ]; then mysql -u$DB_USER -p$DB_PASS $DB_NAME -e DROP TABLE $ARCHIVE_TABLE; echo $(date) - $ARCHIVE_TABLE archived successfully /var/log/archive_cron.log else echo $(date) - $ARCHIVE_TABLE md5 mismatch, keep source table /var/log/archive_cron.log fi这个脚本在真实运行时还需要考虑锁表、错误处理、并发控制等细节但基础框架已经能跑通。我的原则是先把简单能用的逻辑跑起来再逐步完善。生产环境建议用类似PT-Online-Schema-Change工具或者通过MySQL的在线DDL特性来做降低对业务的影响。5. 对比测试设计用同一套查询对比SSD与归档存储的性能差距5.1 测试数据与查询样式的准备性能对比是这次项目的重头戏。为了让测试结果公平我准备了同一张表的两份数据一份完整放在SSD上一份完整放在归档存储上。为了模拟真实场景测试数据集共约300万行建立了两个索引idx_create_time和idx_user_id。对比语句设计了三类典型场景点查Point QuerySELECT * FROM order_record WHERE user_id 12345;范围查询Range QuerySELECT * FROM order_record WHERE create_time BETWEEN 2023-01-01 00:00:00 AND 2023-01-31 23:59:59;聚合查询Aggregation QuerySELECT COUNT(*), SUM(amount) FROM order_record WHERE create_time 2023-01-01;考虑到机械硬盘的顺序读性能其实还可以但随机读性能极差因此点查和范围查询最能体现SSD和归档盘的差异。聚合查询如果走索引扫描在归档盘上也会慢得多尤其是需要回表的情况下。5.2 测试方法和工具我用了两种方式来测量查询性能MySQL自带的PROFILING或performance_schema得到精确的耗时sysbench 的oltp_read_only压测模式用来测试并发场景下的整体QPS和平均延迟。sysbench压测命令示例sysbench /usr/share/sysbench/oltp_read_only.lua \ --mysql-host127.0.0.1 \ --mysql-userroot \ --mysql-passwordyourpass \ --mysql-dbtestdb \ --tables1 \ --table-size3000000 \ --threads16 \ --time60 \ --report-interval5 \ run这里需要注意sysbench默认会自己建表和造数据但我们是已经有一张order_record表了所以可以跳过prepare阶段直接用run指令跑已经存在的表或者按它的格式把表结构调整成sysbench认识的类型。为了测试公平我建议针对自己建的数据表写一个Lua脚本或者直接用SQL脚本循环执行来测单条语句耗时。5.3 单条查询性能实测数据我分别对SSD和归档盘上的同一张表执行了上述三类查询每种查询执行10次取中间值去掉最高最低结果如下查询类型SSD耗时(ms)归档盘耗时(ms)性能差距点查2.838.6约14倍范围查询6.2142.5约23倍聚合查询11.4368.2约32倍这个结果符合预期机械硬盘的随机读性能是硬伤范围查询和聚合查询在缺少覆盖索引时需要大量随机读数据页所以差距会进一步拉大。而SSD的随机读能力远强于机械盘即使数据量很大点查也能保持在几毫秒级别。归档盘上的聚合查询慢到接近400毫秒对在线业务来说肯定是不可接受的但如果你只是做离线报表或者非高峰期的数据分析这个延迟完全可以忍受。这也是冷热分离的意义所在——把慢查询限制在冷数据上不让它影响主业务。5.4 并发压力测试QPS与延迟变化再来看并发场景。我用sysbench跑60秒的只读压测16个并发线程。结果如下存储类型平均QPS平均延迟(ms)P99延迟(ms)SSD72002.24.8归档盘86018.642.3从 QPS 看差距大约是8倍但延迟的P99差距更明显归档盘在并发下有接近42ms的抖动而SSD则非常平稳。实际业务中如果查询并发一旦高起来机械盘很容易变成瓶颈导致数据库连接堆积甚至影响其他正常查询。6. 性能差异背后的原理随机读写、IO队列与缓存机制6.1 机械盘的随机IO为何慢得离谱很多人只知道“机械盘慢”但说不清慢在哪。机械硬盘的读写过程包含磁头寻道、盘片旋转等物理动作每次随机访问都要等待磁头移动到目标磁道这个“寻道时间”通常在几毫秒到十几毫秒。而数据库的B树索引天生就是随机访问模式的即使你只查一条记录也可能需要沿着索引树的层级一路跳转读取多个数据页。每一页读取都是一次随机IO累积下来就是几十毫秒的延迟。SSD没有机械结构数据存储在闪存颗粒中通过控制器直接访问纳秒级就能定位到目标位置所以随机读性能和顺序读性能差距不大。这就是为什么数据库这种随机读密集的应用SSD能带来十几倍甚至几十倍的性能提升。6.2 InnoDB缓冲池对性能测试的干扰在做性能对比时有个隐形的干扰项InnoDB缓冲池Buffer Pool。MySQL默认会将数据页缓存在内存里同一份数据如果已经被读入内存第二次查询就不会触及物理磁盘导致测试结果失真。我为了测真实的磁盘性能在每轮测试前都执行了以下操作清空MySQL的缓冲池缓存SET GLOBAL innodb_buffer_pool_size 0;但注意innodb_buffer_pool_size在MySQL 8.0里是只读参数不能在线设为0。更稳妥的办法是用innodb_buffer_pool_dump_now和innodb_buffer_pool_load_now配合或者干脆重启MySQL这样Buffer Pool是空的。测试环境我直接重启了MySQL确保冷缓存状态下测试才能反映出“从磁盘读数据”的真实延迟。如果你的测试环境不能重启还可以用TABLE命令预热或冷表的方式但最严谨的方式还是重启。6.3 为什么冷数据盘上的“覆盖索引”能救一手虽然归档盘慢但也不是没有优化手段。一个很常见的手段是在归档表上创建覆盖索引尽量让查询在索引叶中返回所有需要的字段避免回表。举个例子如果我们的聚合查询是SELECT COUNT(*), SUM(amount) FROM order_record WHERE create_time 2023-01-01在create_time上建索引后InnoDB会扫描二级索引虽然还是随机读但至少读取的是更紧凑的索引页比回表读整行要快很多。如果你把amount也放到联合索引(create_time, amount)里那么SUM(amount)可以直接从索引里获得完全避免回表这种优化对归档存储的查询收益非常大。我做过一个对比在同一张归档表上不建覆盖索引执行聚合查询耗时368ms建了(create_time, amount)覆盖索引后降到约120ms。虽然还是比SSD慢但至少能接受。7. 数据一致性保障迁移过程中的锁、校验与回滚方案7.1 迁移过程中如何避免数据不一致冷数据迁移最怕的不是慢而是数据不一致。我在最初测试时遇到过一个问题用EXCHANGE PARTITION拆表后如果业务端还有写操作往这个分区插入数据会导致表在拆分过程中丢失部分数据。解决思路有两个迁移窗口内锁定目标表对业务侧透明使用LOCK TABLES ... WRITE等迁移完成后再解锁。缺点是可能导致短时写入阻塞。引入一台只读归档库源库在迁移过程中不需要停写但需要额外做一次增量同步逻辑复杂。我最终选择了第一种方案因为我们是低峰期操作锁几秒到几十秒是可以接受的。锁表语句LOCK TABLES order_record WRITE; -- 执行拆表、拷贝、删除 UNLOCK TABLES;注意LOCK TABLES本身会触发隐式提交需要确保事务已经提交后再执行。7.2 文件完整性校验与常见坑拷贝.ibd文件时一个常见坑是MySQL 正在运行期间虽然表已经被拆出来了但如果还有查询没有释放文件句柄直接拷贝可能导致文件内容不一致。我一般会等几秒确认没有新连接访问这个表后再执行拷贝。文件拷完后除了比对MD5还要注意文件权限。MySQL的datadir文件所有者必须是mysql:mysql如果拷贝到归档目录后所有者不对后面需要用chown修正chown mysql:mysql /data/archive/mysql_archive/order_record_202301.ibd另外如果归档盘的文件系统不支持某些特性比如稀疏文件、大文件拷贝也可能会报错。建议归档盘用XFS或ext4不建议用FAT32这类不支持超过4GB单文件的老格式。7.3 若迁移失败如何快速回滚任何迁移方案都要有回滚预案。我的做法是在迁移前保留源库的独立表不立刻删除直到归档文件校验通过后才启动删除。如果迁移中途失败源表还在可以直接将EXCHANGE PARTITION反向操作把独立表的数据重新交换回分区表恢复原状。反向操作ALTER TABLE order_record EXCHANGE PARTITION p202301 WITH TABLE order_record_202301;如果已经执行了DROP TABLE order_record_202301那就只能通过归档存储恢复或者使用备份文件了。所以我的建议是删除源表之前至少保留24小时确认业务无任何异常再清理。稳妥大于省事。8. 优化与扩展从“手动归档”到“半自动分层”的进阶思路8.1 用MySQL事件调度器定期重命名分区前面的自动化脚本用的是crontab但MySQL本身也支持“事件调度器”Event Scheduler可以定期执行SQL。如果你倾向于尽量少碰Shell可以用事件来实现定期创建新分区和归档旧分区。示例每天创建下个月的分区CREATE EVENT auto_add_partition ON SCHEDULE EVERY 1 DAY DO BEGIN -- 动态拼接SQL添加分区 SET next_month DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 1 MONTH), %Y-%m-01); SET sql CONCAT(ALTER TABLE order_record ADD PARTITION (PARTITION p, DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 1 MONTH), %Y%m), VALUES LESS THAN (TO_DAYS(\, next_month, \)))); PREPARE stmt FROM sql; EXECUTE stmt; END;注意事件调度器默认可能是关闭的需要SET GLOBAL event_scheduler ON;。这种方式适合自动化程度要求高的场景但SQL动态拼接的维护成本略高生产环境要做好充分测试。8.2 从“物理分层”到“逻辑分层”引入归档库与数据生命周期管理当数据量大到单机物理存储完全扛不住的时候单纯的SSD归档盘已经不够了。这时候可以考虑引入独立的归档数据库节点专门存放冷数据。通过MySQL的主从复制或者CLONE插件把冷数据同步到归档节点然后在主库上删除旧分区实现逻辑上的冷热分离。这种架构的好处是主库只保留热数据索引体积更小查询更快归档库独立部署可以跑批量任务不影响主库性能支持把归档库迁移到更便宜的存储服务器比如云上的低频访问存储。缺点是架构复杂度增加数据一致性需要靠binlog或数据同步工具来保证。我们之前被热搜词里反复提到“数据库同步软件”“数据库同步工具”其实正是这类架构落地时不可或缺的组件。8.3 分层后的监控与告警存储分层做完并不意味着万事大吉。我强烈建议对冷热存储分别配置监控指标至少包括SSD的使用率超过80%告警归档盘的写入速率与错误率SMART信息冷数据迁移任务的执行状态成功/失败/耗时归档查询的延迟和失败率我用Prometheus node_exporter 自定义exporter监控磁盘和MySQL状态通过Grafana展示。迁移脚本每次执行完都把成功/失败状态写入日志再用脚本解析日志推送告警到钉钉或邮件。这样任何一次归档异常都能第一时间发现。9. 实测总结与个人心得这套分层架构的收益与成本最后说点实际的。这个分层架构跑通之后收获是立竿见影的SSD空间占用下降了62%热数据查询性能保持稳定归档数据查询按需连接归档库影响可控。整个迁移过程中遇到过几次小问题但都在预案范围内解决了。我个人最大的感受是存储分层本身不复杂复杂的是“判定冷热”和“保证一致性”这两件事。定错了冷热边界可能把本该热的数据归档掉导致线上查询变慢迁移过程中稍微疏忽就可能造成数据损坏或丢失。所以无论方案听起来多完美都要在测试环境反复演练尤其是回滚流程一定要跑通。如果你也准备做数据库存储分层建议从一张具体的大表开始不要一上来就全库迁移。先把流程跑顺观测一段时间的查询延迟、空间变化、迁移耗时再逐步推广到其他表。毕竟数据库架构调整稳永远比快重要。