MySQL 精度扩展时候的DDL阻塞对比Oracle

曾经我分析过在MySQL数据库上字段扩位是否只是快速更新元数据的

• 那次是因为是在实际工作中意外遇到的问题，所以做了实验
• 得出在64以下改变没有问题。64以上的改变也没有问题。但是当从小于64的改到64以上时候则会发生问题。（不是简单的改元数据）
• 当时这个结论使得我们在日常变更中可以判断影响面。

最近有一个新的场景，精度变更

• 出于对上次的判断，我觉得这里有一些不确定性。十有八九会有要注意的问题。
• 事实证明我判断正确的

实际效果

• 模拟一个100M以上的表

mysql> select count(*) from test_data; +----------+ | count(*) | +----------+ | 1000000 | +----------+ 1 row in set (0.74 sec) mysql> desc test_data; +-------+---------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+---------------+------+-----+---------+----------------+ | id | int | NO | PRI | NULL | auto_increment | | m | varchar(30) | YES | | NULL | | | n | varchar(80) | YES | | NULL | | | x | decimal(12,6) | YES | | NULL | | | y | decimal(18,3) | YES | | NULL | | +-------+---------------+------+-----+---------+----------------+ 5 rows in set (0.05 sec) mysql> alter table test_data add z decimal(10,3); Query OK, 0 rows affected (0.13 sec) Records: 0 Duplicates: 0 Warnings: 0 - 可见增加字段是直接元数据变更。 mysql> mysql> alter table test_data modify m varchar(50); Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0 - 可见上次结论，64以下到64以上会耗时较长，数据不仅仅是元数据变更 mysql> alter table test_data modify m varchar(150); Query OK, 1000000 rows affected (49.92 sec) Records: 1000000 Duplicates: 0 Warnings: 0 mysql> alter table test_data modify m varchar(160); Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0 - 而64以上再次改变是，仅仅元数据变更。 - 那么数据精度改变。从实际效果而言，耗时较长。数据重新在做组织。 - mysql> alter table test_data modify x decimal(18,6); Query OK, 1000000 rows affected (47.20 sec) Records: 1000000 Duplicates: 0 Warnings: 0 mysql> alter table test_data modify y decimal(18,6); Query OK, 1000000 rows affected (46.73 sec) Records: 1000000 Duplicates: 0 Warnings: 0

结论很明显了。那么我就想在Oracle下如何表现？

XXG@xxg> desc test_data; 名称 是否为空? 类型 ----------------------------------------------------------------- -------- -------------------------------------------- M VARCHAR2(30) N VARCHAR2(80) X NUMBER(12,6) Y NUMBER(18,3) XXG@xxg> set timing on; XXG@xxg> select count(*) from test_data; COUNT(*) ---------- 2500000 已用时间: 00: 00: 00.38 XXG@xxg> alter table test_data add z decimal(10,3); 表已更改。 - 在11g（2005年）就实现的增加字段是直接元数据变更，是所有数据库都学习和借鉴的。 已用时间: 00: 00: 01.23 XXG@xxg> alter table test_data modify m varchar(50); 表已更改。 已用时间: 00: 00: 00.19 XXG@xxg> alter table test_data modify m varchar(150); 表已更改。 已用时间: 00: 00: 00.16 XXG@xxg> alter table test_data modify m varchar(160); 表已更改。 - 无论如何扩位，都是快速完成。不存在数据重组的问题。 已用时间: 00: 00: 00.15 XXG@xxg> alter table test_data modify x decimal(18,6); 表已更改。 已用时间: 00: 00: 00.16 XXG@xxg> alter table test_data modify y decimal(18,6); alter table test_data modify y decimal(18,6) * 第 1 行出现错误: ORA-01440: 要减小精度或标度, 则要修改的列必须为空 已用时间: 00: 00: 00.39 XXG@xxg> alter table test_data modify y decimal(21,6); 表已更改。 已用时间: 00: 00: 00.05

• 从最后的结果来说，只要精度扩大给到对应的范围，也是毫秒完成变更，不存在耗时长的问题。

这些后续可以更好的判断DDL时候的阻塞情况