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时候的阻塞情况