本文將介紹傳統數據庫在處理大表時所采用的解決方案并分析PolarDB體系下針對這些大表的優化處理方法。
DDL運維能力優化
并行DDL
傳統的DDL操作依賴于單核處理和傳統硬盤設計，這使得針對大表的DDL操作耗時較長，延遲過高。以創建二級索引為例，過高的延遲DDL操作會阻塞后續依賴新索引的DML查詢操作。多核處理器的發展為并行數據定義語言（DDL）的使用提供了更強大的硬件支持。同時，固態硬盤（Solid State Disk，簡稱SSD）的普及使得隨機訪問延遲與順序訪問延遲的差距大大縮小。因此，采用并行DDL技術加速大表的索引創建顯得尤為重要。
PolarDB的并行DDL功能能夠充分利用數據庫的硬件資源，大幅度降低DDL操作的執行時間，避免阻塞后續相關的DML操作，從而縮短DDL操作的窗口期。
并行DDL上線以來，已經成功幫助眾多客戶解決了在大表中添加索引時遇到的難題。根據真實用戶反饋，啟用并行DDL功能后，對于一張5 TB、60億行的大表，僅需1小時即可完成二級索引的添加。
下圖展示了在使用不同并行線程數時，使用并行DDL在不同數據量的表中為數據類型為INT的字段b創建二級索引所帶來的DDL執行效率提升比例?？梢钥吹剑旈_啟32個線程時，最高可實現2000%的性能提升。
秒級DDL（添加字段）
在使用傳統方法進行加列操作時，往往需要重新構建整個表的數據，這會消耗大量系統資源。PolarDB的秒級加字段（Instant add column）功能，在進行加列操作時，只需更改表的定義信息，無需修改已有的數據。
秒級修改字符集
UTF-8編碼是一種廣泛使用的字符編碼方式。在社區版MySQL中，當使用UTF-8時，系統默認采用utf8mb3編碼集。此編碼集最多使用3個字節存儲字符。當需要存儲emoji等信息時，通常需要將utf8mb3字符集轉換為utf8mb4。然而，字符集的轉換往往涉及到表的重建，這個過程可能耗時較長，并對業務造成一定影響。PolarDB支持在秒級內將字符集從utf8mb3修改為utf8mb4。借助這一功能，您可以便捷地完成字符集的轉換，讓您的數據庫更好地支持多種字符和符號。
ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4, ALGORITHM = INPLACE;使用上述語句時，若返回ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.這意味著當前操作無法以inplace算法執行。建議您仔細核對相關的使用限制。
在不指定ALGORITHM或選擇ALGORITHM=DEFAULT的情況下，PolarDB會自動找到執行效率最高的算法來完成修改操作。將列的字符集從utf8mb3轉為utf8mb4時，可以無視表的大小，在秒級完成操作。以下是相關的示例語句：
ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4, ALGORITHM = DEFAULT;
ALTER TABLE tablename MODIFY COLUMN test_column varchar(60) CHARACTER SET utf8mb4;快速Truncate或Drop大表
在社區版MySQL 5.7中，執行TRUNCATE TABLE和DROP TABLE操作時，需要掃描整個緩存池（Buffer Pool），將與表空間對應的所有數據頁從LRU list和FLUSH list中刪除。當Buffer Pool較大時，相關操作可能會耗時較長。為此，PolarDB對DDL過程中Buffer Pool的管理機制進行了優化，從而顯著提升了Buffer Pool的掃描效率，進而加快了TRUNCATE TABLE和DROP TABLE的執行速度。
使用方法
您可以通過loose_innodb_flush_pages_using_space_id參數開啟Faster TRUNCATE或DROP TABLE功能。
使用效果
在不同規格的集群中，記錄了開啟和關閉Faster TRUNCATE或DROP TABLE功能后，對t1表和t2表進行TRUNCATE TABLE操作所需的執行時間（以秒為單位）。其中，t1表插入8196行數據，用于模擬小表TRUNCATE情況，t2表插入2097152行，用于模擬大表TRUNCATE情況。實驗結果如下所示：
集群規格 | Buffer Pool（GB） | t1 | t2 | ||||
ON | OFF | 提升率 | ON | OFF | 提升率 | ||
64核512 GB | 374 | 0.01 | 5.2 | 99.81% | 0.11 | 9.48 | 98.84% |
32核256 GB | 192 | 0.02 | 2.45 | 99.18% | 0.1 | 2.65 | 96.23% |
16核128 GB | 96 | 0.01 | 1.73 | 99.42% | 0.12 | 1.86 | 93.55% |
8核64 GB | 42 | 0.01 | 0.73 | 98.63% | 0.12 | 0.79 | 84.81% |
4核32 GB | 24 | 0.02 | 0.45 | 95.56% | 0.13 | 0.53 | 75.47% |
4核16 GB | 12 | 0.03 | 0.23 | 86.96% | 0.12 | 0.35 | 65.71% |
從上表可以看出，開啟Faster TRUNCATE或DROP TABLE功能后，能顯著提升TRUNCATE TABLE操作的執行效率。
非阻塞DDL
在執行DDL操作時，如果目標表上存在未提交的長事務或大查詢，DDL操作將持續等待獲取MDL-X鎖。在PolarDB中，MDL-X鎖具有最高優先級，因此在等待期間，DDL操作將阻塞對目標表的新事務。這種情況可能導致業務連接的堆積和阻塞，從而嚴重影響業務運行，甚至可能導致整個系統崩潰。
為了解決這一問題，PolarDB針對在線 DDL提供了非阻塞DDL功能。開啟該功能后，DDL語句的鎖策略將與工具（如gh-ost和DMS的無鎖變更）保持一致，確保無鎖或無損地執行業務。同時，由于PolarDB的DDL流程是內核原生實現，其性能顯著優于外部工具，DDL操作將具備類似于外圍工具的無損特性，并保持內核的高性能，從而顯著減少對業務的影響。
使用方法
您可以通過loose_polar_nonblock_ddl_mode參數開啟Nonblock DDL功能。開啟后，在業務高峰期執行DDL時，即使無法獲取鎖，也不會對業務產生影響。
使用效果
關閉Nonblock DDL，TPS持續跌至0。默認超時時間為31536000，嚴重影響業務。
開啟Nonblock DDL，TPS周期性下降，但未跌至0。對業務影響較小，能保證業務系統的穩定。
使用gh-ost進行表結構無鎖變更，TPS周期性跌0。對業務影響很大，這是cut-over階段短暫鎖表造成的。
性能對比：使用SysBench工具下oltp_read_write模擬業務負載，通過下圖可以看出開啟Nonblock DDL并使用傳統的加列方式（INSTANT、INPLACE、COPY）比使用gh-ost工具耗時更少。
總結
從當前云產品的發展趨勢來看，幾乎所有主要云產品提供商都推出了兼容性最強的解決方案，并將其作為云平臺的核心產品。
對于云服務提供商而言，兼容性是最重要的需求之一。對于許多中小型客戶而言，100%的兼容性是一個重要的參考指標?？蛻魧a品遷移至云端時，往往會考慮現有開發人員的技術棧和存量代碼。因此，任何不兼容的情況出現都會導致開發人員需要付出額外的學習成本，同時也會增加對現有業務進行改造的成本，從而給客戶帶來額外的支出。當然，隨著業務的壯大，可能會出現大表影響業務發展的情況，性能不再滿足需求且沒有數據清理方案，那時再考慮相關問題也為時未晚。