?

PostgreSQL 在9.2 之前是要面臨一個指責，就是在更改字段類型的時候帶來的不堪，假象你有100萬行的數據，其中一個字段是varchar(20) ,你想將其更改為 varhcar(30), 這可能就要造成一個災難，熟悉postgresql 原理的人們，馬上就想到，可能要生成一個“新表”了。導致Postgres重寫表的每一行，這可能是一個非常昂貴的操作(就磁盤I/O和掛鐘時間而言)，MYSQL 早期的版本也沒有好到哪里去，可是這對難兄難弟，都會成長。

PostgreSQL 在9.2 之后修改字段的大小，例如 varchar(20) ---> varchar(30) 返回修改僅僅是一瞬間的事情。

所以現在如果還有人說，PG修改字段的大小太差勁，那我到是覺得活在上世紀的 someone 可以清理一下內存了，終歸新的東西是要不斷學習的，你去看看現在的MYSQL 8 如果你的知識還保留在 MYSQL 5.5 ，那你一定也需要更新了。

那問題1 如果你還在使用PG 9.2 之前的版本，并繼續受到這個問題的纏繞，怎么辦

1 升級數據庫版本 (當然這個說法估計支持的聲音不少，但實際上做的人不多，因為牽扯的資源和人太多，沒有人愿意在沒有占有這個數據庫系統的開發或者第三方開發商的支持下去做這個事情)

2 建議將字段更換為text字段，(或者經常需要變動的文字的字段)，

ALTER TABLE test ALTER COLUMN puzzle TYPE text;ALTER TABLE test ADD CONSTRAINT checksum_lengthCHECK (LENGTH(puzzle) <= 32);我們先看看這個方法合適嗎,這個方法當然合適，字段的擴充可以換個思路，我們可以給的無限，然后后面通過約束限制一下，這樣DBA 和開發其實都開心

當然也有人說，你加完約束，系統的性能會受到影響，來來來我們做一個測試，插入1百萬的數據，僅僅需要6秒多.

當然這并不是本期主要的話題，本期的主要話題是

這里要澄清的是，不是所有的PG 的 Alter Column type 操作都要進行重建表的操作(這里先不牽扯索引的事情)

這就是今天要進行測試的表，PG的版本 PG 12.2

測試如下

1 name 的類型從 char 變為 varchar 在變成 text

2 將上面的變化在變回來

將整形從小變大 從大變小，將日期類型進行變化

這些都是需要重寫的

說完這些可能還有些人有疑問

1 添加一個字段呢，添加一個帶默認值的字段呢

2 刪除一個字段呢

3 更改一個字段的名字呢

結果是這些都不需要重寫，另外在PG11 已經解決了關于 默認值的問題，這個問題，其實在有的商業數據庫到很新的版本還是一個問題。

最后是關于索引的問題，這里PG 建立索引盡量要使用

CREATE INDEX CONCURRENTLY idx_add_c on type_change (add_c);

根據PG 的原理來說，我們在建立索引如果不使用 concurrently 參數則建立索引時表要 獲取一個 access exclusive 的鎖，而如果我們使用了 concurrently 則我們會獲得一個 share update exclusive 的鎖。所以使用了concurrently 則會允許在索引建立的同時繼續讀取數據和寫入數據，當然也有一些副作用，今天就不說了，這個 concurrently 其實也可以找一期說一下，也是有點意思。

總結

以上是生活随笔為你收集整理的修改字段类型_PostgreSQL 关于字段类型的修改 谣言与止谣的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。