**背景** 項目的快速迭代開發和在線業務需要保持持續可用的要求，導致MySQL的ddl變成了DBA很頭疼的事情，而且經常導致故障發生。本篇介紹RDS分支上做的一個功能改進，DDL fast fail。主要解決：DDL操作因為無法獲取MDL排它鎖，進入等待隊列的時候，阻塞了應用所有的讀寫請求問題。 **MDL鎖機制介紹** 首先介紹一下MDL(METADATA LOCK)鎖機制，MySQL為了保證表結構的完整性和一致性，對表的所有訪問都需要獲得相應級別的MDL鎖，比如以下場景： ~~~ session 1: start transaction; select * from test.t1; session 2: alter table test.t1 add extra int; session 3: select * from test.t1; ~~~ session 1對t1表做查詢，首先需要獲取t1表的MDL_SHARED_READ級別MDL鎖。鎖一直持續到commit結束，然后釋放。 session 2對t1表做DDL，需要獲取t1表的MDL_EXCLUSIVE級別MDL鎖，因為MDL_SHARED_READ與MDL_EXCLUSIVE不相容，所以session 2被session 1阻塞，然后進入等待隊列。 session 3對t1表做查詢，因為等待隊列中有MDL_EXCLUSIVE級別MDL鎖請求，所以session3也被阻塞，進入等待隊列。 這種場景就是目前因為MDL鎖導致的很經典的阻塞問題，如果session1長時間未提交，或者查詢持續過長時間，那么后續對t1表的所有讀寫操作，都被阻塞。 對于在線的業務來說，很容易導致業務中斷。 **aliyun RDS分支改進** DDL fast fail并沒有解決真正DDL過程中的阻塞問題，但避免了因為DDL操作沒有獲取鎖，進而導致業務其他查詢/更新語句阻塞的問題。 其實現方式如下: alter table test.t1 no_wait/wait 1 add extra int; 在ddl語句中，增加了no_wait/wait 1語法支持。 其處理邏輯如下: 首先嘗試獲取t1表的MDL_EXCLUSIVE級別的MDL鎖: 當語句指定的是no_wait，如果獲取失敗，客戶端將得到報錯信息：ERROR?: Lock wait timeout exceeded; try restarting transaction。 當語句指定的是wait 1，如果獲取失敗，最多等待1s，然后得到報錯信息：ERROR?: Lock wait timeout exceeded; try restarting transaction。 另外，除了alter語句以外，還支持rename，truncate，drop，optimize，create index等ddl操作。 **與Oracle的比較** 在Oracle 10g的時候，DDL操作經常會遇到這樣的錯誤信息： ora-00054:resource busy and acquire with nowait specified 即DDL操作無法獲取表上面的排它鎖，而fast fail。 其實DDL獲取排他鎖的設計，需要考慮的就是兩個問題： 1\. 雪崩 如果你采用排隊阻塞的機制，那么DDL如果長時間無法獲取鎖，就會導致應用的雪崩效應，對于高并發的業務，也是災難。 2\. 餓死 如果你采用強制式的機制，那么要防止DDL一直無法獲取鎖的情況，在業務高峰期，可能DDL永遠無法成功。 在Oracle 11g的時候，引入了DDL_LOCK_TIMEOUT參數，如果你設置了這個參數，那么DDL操作將使用排隊阻塞模式，可以在session和global級別設置， 給了用戶更多選擇。