對比上次MySQL的DDL
MySQL的DDL未必都是可以快速完成的,那麼Oracle同等場景下如何?
這個是在Oracle19C下的實驗,特別說明。因為在Oracle11G下有些結論是不成立的。
表thousand有大約4000萬行記錄
SQL> set timing on;
SQL> desc thousand;
Name Type Nullable Default Comments
---- ------------ -------- ------- --------
ID INTEGER Y
A INTEGER Y
NAME VARCHAR2(10) Y
TIME DATE Y sysdate
SQL> select count(*) from thousand;
COUNT(*)
----------
40000000
Executed in 0.69 seconds
可以看出和之前MySQL實驗的的表結構幾乎一模一樣。資料量是MySQL的4倍。
下面對這個進行增加欄位的DDL。
SQL> alter table thousand add address varchar2(100);
Table altered
Executed in 0.098 seconds
98毫秒完成。這個命令在11G是不可能這麼快的。
再對這個表進行增加欄位的DDL,帶有預設值和非空約束。
SQL> alter table thousand add status varchar2(20) default '0' not null;
Table altered
Executed in 0.092 seconds
92毫秒完成。這個命令在11G是也是同樣效果。再對這個表進行增加欄位帶有預設值。
SQL> alter table thousand add QQ varchar2(10) default '0';
Table altered
Executed in 0.022 seconds
22毫秒完成。這個命令在11G是不可能這麼快的。
接下來要進行擴欄位,直接從10長度擴大到70.
SQL> alter table thousand modify name varchar2(70);
Table altered
Executed in 0.061 seconds
61毫秒完成。這個命令在11G是不可能這麼快的。而且也沒有MySQL的超夠64就會重新構建的問題。
SQL> desc thousand;
Name Type Nullable Default Comments
------- ------------- -------- ------- --------
ID INTEGER Y
A INTEGER Y
NAME VARCHAR2(70) Y
TIME DATE Y sysdate
ADDRESS VARCHAR2(100) Y
STATUS VARCHAR2(20) '0'
QQ VARCHAR2(10) Y '0'
那麼從70再次擴充套件到更大的長度會如何?
SQL> alter table thousand modify name varchar2(200);
Table altered
Executed in 0.021 seconds
21毫秒完成。
SQL> desc thousand;
Name Type Nullable Default Comments
------- ------------- -------- ------- --------
ID INTEGER Y
A INTEGER Y
NAME VARCHAR2(200) Y
TIME DATE Y sysdate
ADDRESS VARCHAR2(100) Y
STATUS VARCHAR2(20) '0'
QQ VARCHAR2(10) Y '0'
嘗試一下縮欄位長度的DDL。這個在MySQL中會較為漫長。
SQL> alter table thousand modify address varchar2(50);
Table altered
Executed in 1.614 seconds
1.6秒完成。雖然沒有毫秒那麼快,但是的確也不慢。
再次擴大長度和縮小長度。
SQL> alter table thousand modify address varchar2(500);
Table altered
Executed in 0.015 seconds
SQL> alter table thousand modify address varchar2(120);
Table altered
Executed in 1.544 seconds
比較穩定的都是不到20毫秒的擴容和1.5秒左右的縮容。
這些都是19C版本帶來的。
之所以要講這個主要是有時候開發人員問這個操作會執行多久?(擔心鎖表時間),我第一句話就問?什麼版本?如果19C,那麼基本不用擔心。
SQL>
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/637517/viewspace-3006067/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- PostgreSQL 資料庫結構(DDL)比對工具 pgquarrelSQL資料庫
- MYSQL引擎的鎖對比MySql
- mysql的DDL操作對業務產生影響測試MySql
- MySQL DDL操作表MySql
- MySQL DDL執行方式-Online DDL介紹MySql
- 04 MySQL 表的基本操作-DDLMySql
- mysql DDL時鎖表的排查MySql
- mysql 原生 線上DDL 的bug .MySql
- MySQL 資料對比MySql
- 對上次的自動掃描進行改造
- MySQL Online DDL詳解MySql
- MySQL的DDL和DML操作語法MySql
- TIDB和MySQL效能對比TiDBMySql
- MySQL對比清除不必要的表MySql
- oracle Mysql PostgreSQL 資料庫的對比OracleMySql資料庫
- 與MSSQL對比學習MYSQL的心得MySql
- 【Mysql】MySQL 5.6中如何定位DDL被阻塞的問題MySql
- MySQL(十三)DDL之庫和表的管理MySql
- MySQL入門---(一)SQL的DDL語句MySql
- MySQL高可用架構對比MySql架構
- MySQL 半同步 與Raft對比MySqlRaft
- MYSQL如何比對版本號字串MySql字串
- mysql之 openark-kit online ddlMySql
- MySQL 線上DDL "gh-ost"MySql
- MySQL & MariaDB Online DDL 參考指南MySql
- MySQL - DDL詳解(Data Definition Language)MySql
- 詳談 MySQL 8.0 原子 DDL 原理MySql
- PostgreSQL初體驗及其與MySQL的對比MySql
- MySQL 中如何定位 DDL 被阻塞的問題MySql
- MySQL全面瓦解4:資料定義-DDLMySql
- MySQL5.7 InnoDB線上DDL操作MySql
- MySQL之資料定義語言(DDL)MySql
- MySQL DDL Waiting for table metadata lock 解決MySqlAI
- MySQL線上DDL工具 gh-ostMySql
- MySQL 5.6中如何定位DDL被阻塞的問題MySql
- 取消上次ajax
- mysql匯入匯出指令碼的區別對比MySql指令碼
- PG和MySQL詳細的一些特性對比MySql