這個故障時間比較久了，那時還是21年，我們一個業務有個庫需要做表結構變更，當時我們的數據庫變更規范，工單審批等流程都不規范。而且這個DDL變更工單是被之前不熟悉PG庫的MySQL庫DBA審批後自動執行了，審批後立即出現CPU，連接數等告警，業務報錯等情況。
業務SQL：
ALTER TABLE t_tablename_order_info
ALTER COLUMN order_id TYPE varchar(64),
ALTER COLUMN service_type TYPE int4, 問題SQL
ALTER COLUMN service_types TYPE varchar(64);
其中service_type原先的 類型是int2，本次變更是想擴展該類型，容納更大更多的數據。
後續經過分析和復盤，得出結論和改進計劃：
PG數據庫變更規范：
1，每天的 【業務高峰期】不批工單，錯峰審批，這樣可以盡可能的減少生產環境影響。
2，PG原則上不允許變更數據類型，類型變更可能會重寫數據，表不可用，可能產生業務故障。
3，PG僅支持varchar(N)擴容長度，varchar縮容也會重寫數據，表不可用，可能產生業務故障。
4，PG的int2類型變更為int4會重寫數據，表不可用，可能產生業務故障。
5，DDL變更平臺限制不允許使用int2類型，但是對於已有的表結構改變類型必須做出強提醒。
6，PG11版本前，表增加字段不允許直接加默認值，可以先加字段再加默認值，之後的版本可以。
7，工單審批人員，審批工單時需要註意風險SQL一欄，提示有風險的需要和研發確認，或者和同事溝通，不清楚的不能直接審批，DBA要知道自己所有的操作影響范圍和結果。
其他方面的問題：
當前一個同事審批了工單，其他同事看不到，不清楚數據庫做了什麼事情？
本次也是發現DB存在變更SQL時，問了同事才知道有表結構變更，最好是運維同學能夠清楚自己同事做了哪些審批？工單系統要支持所有自己團隊內部同事都能看到最近審批的工單。
當然現在這些問題都已經全部解決或者規避掉了，其他庫如mysql、oracle等應該也有類似的場景或者情況，你們是否都有遇到過這種情況，另外你們都是如何處理的呢？