【七天深入MySQL實戰營】答疑彙總Day6 MySQL表和索引優化實戰

【開營第六課】【MySQL表和索引優化實戰】

講師：田傑，阿裡雲進階運維專家。

課程内容：InnoDB表和索引設計最佳實踐；索引設計的分析與優化。

答疑彙總：特别感謝班委@李敏 同學

https://help.aliyun.com/document_detail/129925.html

 大家有時間建議看一下這篇文檔，很多實用的功能，無論是雲上還是雲下都是比較好的解決問題思路參考

1. Mysql 有沒有類似 oracle 的快速單表恢複？

A：rds / polar for mysql 都是有的

2. 在什麼場景下，适合建 hash 索引？

A：5.7之下，包括 5.8 初期都是沒有 hash join，5.8 最新有沒有記不得太清楚了，pg 都是有 hash join 的。hash join 适合用在長字元串的等值比較，不能是 like、match、against，不能是模糊查詢，也不能是全文索引，隻能是等值比較；而且是長字元串，什麼叫長字元串，像 abc 這種長度就沒必要，五個六個七個八個沒必要，可能适合在像 二三十個，三四十個，這種長度的字元串，我說的是字元串，字元串做比較，每個字元，像 utf8 是三個位元組來表示，utf8amb 就是四個位元組，這種長字元串的等值比較，适合用 hash join，隻能做等值，因為本質是要做 hash 值比較，不能支援範圍，比如說短字元串，十以内，十五以内，這種長度的比較，其實也是沒必要的。在 pg 裡面也是比較少用 hash join 的。

3. 運作中生産環境上，myisam 表是否不停機下線直接轉換成 innodb，表中有資料，需要注意什麼嗎？

A：轉換後是否還有需要調整的地方嗎？rds / polar for mysql 環境下，大家是不可能建成 myisam 表來的，尤其是新購的執行個體，就我們預設在核心這一塊會有一個轉換，大家指定 create table engine = myisam，即便寫 myisam，也會被替換成 innodb，本身 myisam 的表是建立不起來的，比如說特别老的一些執行個體，像一些存量的 5.5，可能還能支援 myisam，非常少的 5.5。myisam 表不停機，這種情況，首先得搭建一個複制關系，用 dts 搭建一複制關系，或者自己寫 triger，但 trigger 實際上是對事務、業務是有侵入性，我們不太建議，要麼就自己搭建一個 dts 的這種複制關系，從 myisam 同步到 innodb，它隻讀的情況下，對執行個體的壓力還好，搭建一個複制關系，然後等到業務割接的時候做切換。

4. 我公司有張表有兩千多萬資料，使用的UUID作為主鍵，沒有使用到自增列（這個曆史原因），sql 語句：select count(1) cnt from table name where StartDate>=‘2020-11-01’ and StartDate < ‘2020-12-01’ and State=‘C’ and Source=‘Alipay’ 查詢大概平均七分鐘左右，StartDate，State，Source 都有索引，老師有什麼好的優化建議嗎？

A：首先這個查詢裡頭，startdate 的兩個邊界，直接跨度一個月了，state、source 可選的值也不太多，如果真正想解決這個問題，如果這個查詢真的運作非常頻繁，經常要跑的話。首先第一件事，如果是取count，把它變成每天單獨算一下，每天取一個sum值，把它的 count 取出來，然後把業務改造一下，如果我算每個月，我把每天的 count 相加就可以了，做這種事情，因為 select count，不管是 count(1) 還是 count(*) 也好，建議使用 count(*) ，它本身在 innodb 引擎表裡面是怎樣執行的呢？還是選擇最小的索引，它會掃一下，滿足這個查詢條件，上面最小的索引是誰，然後它會掃這個索引，實際上是全索引掃描；如果沒有合适的索引，就會做全表掃描，全表掃描實際上就是掃主鍵，把主鍵跑一遍；如果有合适的索引，會做全索引掃描。如果資料量确實比較大，而且時間跨度也比較大，沒有什麼太好的辦法，因為你這個過濾性是比較差的，三個條件加一塊，可能過濾性不太好，是以建議是每天出一個 count 值，然後 count 值相加就好了，這個比較好，能比較快的解決問題。如果不行的話，如果業務上不改造的話，建議你做一個組合索引，就把 state、source、startDate，你組合在一起，做一個組合索引，然後看一下 state 和 source ，是哪個改動量比較小，它不經常做 update，像 state 我覺得可能會經常做 update，可以把 source 放在第一個字段，把 state 放在第二個字段，把 startDate 放在第三個字段，做一個組合索引，看看這個組合索引的過濾性怎樣，尺寸怎樣，如果尺寸不太大，過濾性還比較好，做這麼一個組合索引，看一下 count(*) 的執行計劃，跑這個索引就好了，就不要再跑 primary key，不要跑原表，但是還是建議，在業務方面該，業務方面在每天做一個 count(*) ，明天算今天的值，最後做加法就好。

5. 單 rds，10億大表，做優化的思路是怎樣的？

A：十億大表的話就隻能拆，如果不用分庫分表的話，這種 drds 也好，polar-X 也好，我們 drds 現在已經改名叫 polar-X了。十億大表你現在隻能去拆，有幾種方法。第一種方法，考慮冷熱資料，十億大表不可能全部都是熱的資料，不可能目前正在跑的業務，這十億資料都需要加載到記憶體裡頭，很有可能不是這樣的，那怎麼辦？拆成兩張表，一張冷表，一張熱表。保證最頻繁查詢的，就是最近兩周或者一周的資料，這些資料在一塊，可能才三千萬，五千萬的，做成一張表，五千萬大小的一張表，性能上一般是不會有多大問題。剩下的我做成冷資料，冷資料要考慮是拆成多張表，還是拆成，如果是拆成多張表的話，每張表的資料會比較平均；如果你要是拆成一張表的話，可能也得有八九億，操作起來也很痛苦。是以第一個考慮冷資料，第二個按業務角度拆，比如說你的業務是全國的，全國有多少個省，按省的次元拆，我查詢經常是按照省的次元查，或者位置也好，時間也好，看按哪個次元拆分。拆的話有兩種，第一種做分區，不太建議使用分區表，還有一種是自己去拆，我寫一個函數，我的查詢每次，都先通過這個函數，把這個表名确定下來，相當于是自己做一下拆表，這是比較好的方法，否則十億大表，真的是不太好處理。

6. Rds 和 drds，單表的列數多少合适？

A：單表的列數不要太多，50 個左右是比較合适的。大家知道 tp（transaction process）類型的業務，本身是短平快的：查詢簡單，業務邏輯簡單，然後快速地執行，對 rt（response time）要求是很敏感的。比如業務的一個動作，可能會有 5/6 sql 組合在一起，如果每個 sql  執行的時間，rt 很長，組合在一起是會有問題的。我們之前和某家銀行，它做這個業務邏輯，它做一個登陸操作，要做 15 個sql，才能完成一個登陸操作，這樣的情況下，要求 rt...。因為登陸操作對 rt 很敏感的，我手機登入也好，網頁也好，你登陸的時候登陸不上去，對使用者體驗來說是一個緻命的硬傷，那你如果想控制 rt 的話，就要保證它這個裡面的動作簡潔有效。像 tp 類型的業務，短平快，是以你這個表設計不要太複雜，弄一個大寬表，大寬表一般是 ap（analysis process）類型的業務，比如出報表，做分析，挖掘資料，做預測，是吧。是一定要考慮你的 ap 和 tp 是要分開的，不能說 tp 和ap 混着用，小業務說沒問題，是吧，不這麼講究，到了一定尺寸、一定體量，還是要分開的。

7. 因為業務需求，不能使用自增主鍵，不得不使用還是 UUID 當作主鍵的時候，怎麼操作會更高效一些？

A：你要用 UUID 也沒問題。用 UUID，隻要對 inset 這種操作，我加載資料，沒有太高的要求。比如說，我們之前碰到的這個客戶，它是對 insert，就是我加載資料，往裡面插入資料，有很高的要求，對資料寫入的 rt 是有很高的要求的，一個是要保證，每秒鐘寫入多少資料，因為他有很多的采集點，要保證把這些資料，它要寫到這個庫裡去，否則它跟不上了， 背景資料寫入跟不不上，前台資料吐不出，這樣的話，會對他造成一個瓶頸。你如果說沒問題，我 1s 就寫10條，用 UUID 沒問題，100ms 寫一條資料，還是可以的，但是表不要太多。

8. Drds 百億大表如果做查詢優化？

A：百億大表，做 ddl 管理是很困難的，而且你的有足夠大的記憶體，還有你索引的效率可能會下降，是以一個表不要弄得太大。百億肯定是要拆表了，一般情況下，你考慮這個拆表，裡頭是有建議值的，一般的 mysql 單執行個體，這個表最理想的尺寸是存，一千萬資料量，五個 GB 資料尺寸。五千萬也可以，六千萬也可以，十個 GB 一張表，沒什麼太大問題，那個是理想經驗值。當然你說我到了 百億，這個表的尺寸，絕對不能說是 十幾個GB，二十個GB，除非你裡頭插的都是 int，都是整形值，這是不太可能的。那你到百億了，你那個表可能得幾百個GB，你到這個尺寸了，即便 mysql 最大的 rds 執行個體，470 GB的記憶體，承 70%，你放這一張表也不可能，它還有二級索引，這表上肯定還會有二級索引呢，是以還是要拆，而且這張表上是不是這些資料嗎，全是我業務目前正在用的，從業務角度看一眼。

9. 虛拟列設定為不持久化，請問資料結果存儲在記憶體中嗎？

A：如果是的話，那重新開機資料庫還需要重新計算虛拟列結果到記憶體中，是嗎？沒有太多的研究，5.8，8.0 新出的這個。

10. 關于索引字段，是說 varchar 100 是要比 varchar 250 好很多是嗎？是以關于索引字段的類型及長度應該更準确？

A：這個 varchar 的問題，實際上它要跟你的字元串實體來呀，最好的情況下是不要把它弄得太長，不是說 varchar 100 一定比 varchar 250 好很多，不要弄得太長。

11. 請問高可用和主從同步一緻性，您一般采用什麼架構呢？

A：首先說一點，主備執行個體之間不是同步複制，同步複制什麼意思，就是主執行個體、備執行個體，做事務 commit 送出的時候，我要保證兩遍的事務日志都要同步落盤，mysql 沒有幹這種事情的，oracle 有，但是 o 真正做這種datagate 也好，三個模式裡面選擇一個最安全的，資料安全的，這個不可能的，因為你走網絡的這樣，主庫被備庫拖累是很嚴重的，嚴重影響你的 rt。而且網絡波動，大家要有一個概念：網絡是不可靠的，網絡協定為什麼這麼複雜，都是處理二般情況的，一般情況都很好處理。是以說這個網絡波動，是以是沒有用同步複制的，都是異步複制，或者是半同步複制。那這種中間肯定是會出現這種...。資料一緻性和高可用之間是有一個沖突關系，隻能是我在這種場景，或者技術條件下，我有一種妥協。我們這邊的架構，實際上都是主備複制，咱們的 rds 預設都是半同步複制，大家如果再公共雲上，開一個 rds ，如果不做任何操作的話，預設，不能選高性能模版，選那個最基本的性能模版的話，出來的都是半同步複制。半同步複制，是要求主執行個體事務送出的時候，就commit的時候，也許是自動，也許是手動 commit，也就是隐式/顯式 commit 的時候，備庫是要能收到主庫對這個事務，所有的事務資訊是要發過來的，發過來的情況下，我不落盤，但是我要收全了，也就是我的 receive buffer 要收到，并且我的 receive buffer 要通知到 mysql 的，mysql 要認為我這個事務收全了，mysql 要讀到結束的标志位了，這個時候它會把這個，傳回一個 ack 給主執行個體，主執行個體收到這個 ack 之後，主執行個體才會把這個 commit 送出成功，傳回給應用。意思是說，在主執行個體上，你是看到事務送出成功，那麼表示至少有一個備執行個體，它拿到了主執行個體上面的事務資訊的。

12. Mysql 服務每次重新開機都特别慢，mysql 程序一直在讀資料，3306 程序要兩個小時左右才能起來，庫裡共 1T 左右資料，這種情況是什麼原因導緻的？

A：重新開機特别慢，實際上跟蹤下，看它到底在幹什麼。有可能，是不是你的 innodb buffer pool 給 dump 到磁盤上了，啟動的時候，是要這個加載回去的，實際上你也跟蹤一下，看它在幹什麼，mysqld 啟兩個小時才能起起來，實在是有點時間太長了，最好是做一下跟蹤，看一下他到底是在幹什麼，就你 debug 一下。

13. 請問主從複制時，從庫開啟多線程複制時，如何保證從庫應用主庫 binlog 的執行順序，例如：A事務建立表 T，B 事務向表 T 中插入資料 1，兩個事務的 binlog 同時複制到從庫上，此時多線程會不會先應用 B 事務？是如何保證先應用 A 的？邏輯時鐘的執行原理是咋樣的呢？Mysql 複制？多線程複制，它本身是表級别的，就是我按照表級别的，我一個表一個線程，他是這樣，mysql 官方最開始是按照庫級别的，後來改成表級别，我們這邊一開始全都是按照表級别的。

14. 表分區可以作為查詢優化的方向嗎？

A：分區表作為查詢優化的方向，分區表，它有一個最大的問題，就是分幾個方面。第一方面，它是對主鍵是有要求的，主鍵和分區鍵，是需要都定義在分區鍵裡的，我的分區鍵都是要包含主鍵的，或者是要包含一個唯一鍵也可以，這是一個問題，就是我在做這個分區設計的時候很非常不友善，就是我要把這個主鍵放進去，這是第一件事；第二件事呢，就是它本身，mysql 的分區設計比 oracle 的靈活性還是要差一些的，差一些差在哪裡呢，始載于它沒有那麼多的這種排列組合，oracle 支援 range list、list range、range hash、hash range，反正怎麼折騰都行，排列組合都是可以的，mysql 還是有些限制的；它最大的一個問題是在于，分區表下面的這個資料檔案是有多個的，每一個分區實際對應的是一個資料檔案，innodb 的一個檔案，但是它的這個鎖隻有一個吧，就是我的這個 mdl 鎖，就我做 ddl 的時候，就是我做 ddl 的時候，首先要拿到 mdl 鎖，我的 mdl 鎖隻有一把，就是我如果一旦對這個表做 ddl，做管理操作，那這個表下面所有的分區都會受影響，也就是說，對資料庫管理者非常不友好，這個是最大的問題，從業務角度來說還好，因為業務本身對 ddl 不是很敏感，不會經常去跑做那些 ddl 的，如果說我管理者願意麻煩一點，那麼也ok。如果分區規則滿足業務的需求，你使用分區也沒什麼問題，對管理者，對 dba 非常不太友好，通常情況下，我們不太建議用。尤其是什麼情況，咱們有的同學做業務設計的時候，喜歡規劃三年，規劃三年的時候，他按分區的時候，他可能不是按照月分區，而是按照天分區，然後搞得好多表會出一堆特别碎的檔案，一張表下面可能會堆好多好多的檔案，它每個分區都會做出一個檔案，你這種情況下呢，他這個檔案會非常多，首先第一個你會吃這個檔案描述符，這是一件事；就是 mysql 在檔案特别多的時候是有問題的，檔案特别特别多，什麼情況，就是幾十萬這種場景，rds 說一個值，rds 超過 40W 資料檔案的話，這是沒法做備份的，做備份會很困難，基本上做不了，超過 40W，我們的建議值，就是你表的總數量保證在 6/7W 以下，否則對性能是有影響的，是以即便做分區，不要說我規劃地非常遠，搞得下面幾十W 個檔案都是分區檔案。

15. Optimize table，結果表大了很多，這是為什麼？

A：如果确實是這種情況的話，首先第一件事情，把 optimize table 改成 alter table，然後要去加參數的，把 algorithm 從 inplace 改成 copy。改成 copy 的話，是強制要複制表的，但是注意如果你改成 copy 的情況下，你的表是被鎖了的，不能寫隻能讀，這種情況下，它是強制複制表。一般情況下，如果你那個表裡面真的有很多空洞，有很多空間浪費的，它是能收縮回來的，它那個背景會變成：建立一張新表，把資料倒騰過去，它會變成這種算法，但是它是鎖表的。一般情況下，我們不太喜歡用 optimize table，我們都會用 alter table，後邊加上 engine = innodb ，這樣加參數的，algorithm 控制它的方式，lock 控制它加不加鎖，是要用這種方式的。5.8.8.0 的這個版本會好很多，好多事情都是不用這個再去改這個表結構的，它事實上改一下中繼資料就好，而且有些操作，它是支援新的這個 instant 的，5.8.0 以下 alter table 隻支援 copy 和 inplace 這兩種方式，5.8 支援 instant，好多操作如果做 instant，會省事很多。技術在發展，我建議大家上來，不要直接做 optimize table這個指令。大家可以看一下，在 innodb 裡面，optimize table 等于兩條指令的，變成 alter table 表名 engine = table，它先做一件這件事；第二件事它做一個 analyze table，它變成這兩件事情。但是它做那個 alter table 是不加參數的，不加的情況下，會有一個問題，就是它有可能會偷偷摸摸地幫你降級，如果你這個表這個操作不滿足 inplace 和 lock = none，它是不會報錯的，它直接幫你降級，是以有可能會鎖表，而且用 inplace 這種方式，它有可能出來之後，表的空間收縮是不明顯的，因為它實際上是一個偷懶迂回的政策。如果你為了收縮空間，用 copy 這種方式會是比較好的，但是注意 copy 是要鎖表。我們建議還是用 dms，或者是其他的工具，比如像 gost，也有同學喜歡用 percona 的 online schema change，那個也可以，但那個似乎是有點慢，它那個實際是基于 trigger 的，對外鍵實際上是有特殊考慮的，gost 也是對外鍵有特殊考慮的。

16. 20億條資料的表，加字段，大緻會加一個星期左右，加字段會導緻表不可用，怎麼解決？

A：幾種方法：一種方法，新買一個執行個體，新買一個 rds 執行個體，拿 dts 把資料同步過去，在 dts 的同步的時候，你在那張表單獨做一個任務，然後把這個表做個映射，那邊建立一個表做個映射，這種最後做切換，這是一種方式，這種情況不影響原執行個體的業務，如果再做執行個體上做 ddl 操作，做一個星期，這個是很危險的事情，因為如果你做原生的 ddl，它是有兩次縮表的，在最開始和結束的時候，它那個 dml 鎖是有兩次鎖更新的，拿到這個互斥的；當然在 8.0 這個加字段，就不是什麼太大的問題了。

17. 硬連結删表是怎麼操作的呢？

A：這是日常做這種線下的庫吧，在 Rds 是沒有這種硬連接配接删表的，他怎麼做的呢。我們會發現一個問題，在 rds，這種大表，做 truncate 或者 drop 的時候，truncate 實際上也是先 drop 掉，再create，這種是要把記憶體是要掃一遍的，然後本身對 io 有是有比較大沖擊，是以我們的 rds 是做了優化，她是對這種大表是做異步的，我對大表做 truncate 還是 drop，都是背景在删除的，這個對前面沒有什麼太大影響。大家如果線下，如果硬連結，實際上是檔案句柄，有多個檔案句柄對這一個資料，隻要檔案句柄還剩下一個，那麼這個檔案就還存在，說白了就是偷梁換柱。

18. 資料少不需要加索引，那什麼時候加（資料越多增加索引代價就越大）？

A：索引這事，首先要看查詢，大家優化的時候，首先要關注慢查詢，mysql 為什麼要把這個慢查詢首先一個單獨的日志，這個慢查詢實際上是很重要的，大家日常是要去掃一掃慢查詢的，慢查詢裡面大家要去關注什麼。執行頻次非常頻繁，掃資料量多，執行時間長，這三個條件來選。而且它是這種這種一層一層的，就是割韭菜一樣，割掉一批再出來一批。你先把這個 mysql long query time 參數預設是 1s，先找這種 1s 以上的，性能特别不好的。先改成 3s 或者 5s，先把這些慢查詢幹掉，幹掉一批，優化完了之後，再找 1s 以上的，處理掉，再找 0.5s 的，不要一上來把 long query time，long query time 設定得非常低的話，會發現慢日志裡面的條數會非常多，人的處理能力實際上是很有限的，一次應付個十幾條，一下子出來 3w 多條慢日志，在叢裡頭摘可就費了勁了，這就稻草裡頭長根針，别幹這種事情，即便是 CPU 打滿了，如果抓不到現場，你要去看慢日志的話，也是這種方法。好多這種同學，我們也碰上好多項目，也是一上來就是 0.1、0.03，定着這個值。出事的時候，生成 36GB 的慢日志，你說這個慢日志怎麼分析。資料少的時候不要加索引，表裡頭幾百條，上千條，幾千條，這種是沒必要加索引的，到了十幾萬的時候，你是要考慮加索引的給表裡頭的資料，主要是要看看這個表是不是經常用，如果是像配置表，裡頭三千行資料，這個配置表加不加索引，如果隻是個配置表，它使用的頻率是比較低。我舉個例子，酒店的業務，會員級别表本身使用頻率是非常低的，在記憶體裡頭就保留很少一塊，你給它加索引不加索引沒什麼意義，會員級别也就就十來個，表裡頭就十幾行資料。

19. Where 條件中 like 雙邊都有 % 号，怎麼優化走索引，場景是文本比對？

A：首先你看查詢條件後面，insert / delete 都一樣的，首先去看 where 條件以後的條件，去看 where 條件子句，根據這個子句，去考慮建立什麼樣的索引。Like 雙 %，有幾種情況，但是最好的方法是，把它放到 es（elastic search）裡頭，或者 adb 裡頭，我們的 adb for mysql，這種模糊查詢最好是放到那邊去處理，這叫術業有專攻。真的靠資料庫雙 %，有在特别特殊的場景下，你 force index，讓它走like 對應的字段，全索引掃描，有可能性能會比優化之前會好，這個是很特别的場景，是有強烈的限制條件的。我們不能說把這個作為通用的方法，我們之前優化過，它那個場景沒辦法走 es ，頁來不及放到 adb，沒有搭建 es，查詢還非得是加 %走，我看它那個表，表裡頭資料是比較特殊的，它裡頭可選的值并不是很多，這是讓它去 force index，那個 index 會比較小，掃 index 全掃描一遍，速度反而會比它掃描全表要快，它這個是非常特殊的場景，如果是文本比對，你要看看你是不是要做分詞，做全文檢索，全文檢索必須要用全文檢索的引擎，還是用 like %，它出來的結果其實是不一樣的。

20. 為什麼全文索引中，無論任何查詢條件都會 explain 出使用索引？比如 id + age + 那麼，建立一個三列的索引，即便單獨使用 name 的等值查詢，也會 explain 出索引？我建議大家不要考慮在 innodb 裡面做全文索引，它對 ddl 是有影響的。在 8.0 以前，5.7、5.6 這兩個版本，如果你這個 innodb 表建過全文索引，全文索引即便已經删除了，後邊你在做 ddl 操作的時候，好多 ddl 是不能用 inplace 這種操作去做的，隻能用 copy 去做，這是 mysql 的限制，是以不要在 mysql 裡面做全文檢索，不太好用。

21. 達到什麼條件需要進行分表？

A：資料量大了，查詢慢了，索引的效率下降。或者是你管理上不好管理，那你就考慮要分了，最好是分某個資料。

22. 建議在生産大規模使用 mysql 8.0 MGR 架構嗎？有無普通主從複制穩定？

A：Mysql 8.0 mgr，我們是阿裡雲，我們隻能推薦我們自己的産品，關于 mgr 這個架構，就不太多說，不太深入的說。

23. 對億級大表的查詢（字段很少 5 ～ 10）每次 explain 執行計劃總是變，我們是靠 force index（時間列二級索引）來解決的，從原理上，這種情況怎麼回事？

A：執行計劃變這種事情，不光是 mysql 裡面出，oracle、db2、pg 也出，隻要是這種 cbo（cost-based optimizer） 模型的，肯定會出，大家說這種事很好解，大家到 rds 上，rds 都是有綁定執行計劃，有綁定執行計劃的 profile，上官網看看 rds 的新特性，新特性裡面都有，不用去改 sql，加force index，hint了，因為你改 sql 的話，是要改業務的，我們這邊直接綁定執行計劃的，綁定就行了。

24. 單表列數 10 列左右比較合理是嗎？剛才沒有聽清？

A：單表列數，經驗值是 50 列以内，10 列太少了，50 列就好了，當然這隻是經驗值，供大家參考。

25. Drds 5.1.28 分庫分表 128 分庫，整個邏輯表 70 億資料，4T 大小，這種情況下增加字段有什麼建議？

A：Drds 加字段，建議大家，第一個 drds 更新到最新的一個版本，最新的版本 ddl 管理方式和之前是不一樣，新版本的 ddl 會比之前有很多增強；第二點是 drds 上加多 ddl 這種事情，一定要對 rds 有一個監控，因為下面可能挂了，我印象中挂了最多，就是 1 個 drds 後面挂了 256個rds 執行個體，就是你做一個 ddl，分發到每一個 rds 上，每個執行個體都要跑的，是以說這種多了什麼情況都會有，mdl 鎖的問題可能是最嚴重，或者說性能的問題會碰到比較多，是以 ddl 操作一定要在業務低峰期，同時有個監控去看一下。