曾经我分析过在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时候的阻塞情况