曾经我分析过在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: 0mysql> 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- 从最后的结果来说，只要精度扩大给到对应的范围，也是毫秒完成变更，不存在耗时长的问题。