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

来源:这里教程网 时间:2026-03-01 18:34:24 作者:

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

  • 相关推荐