1. 首頁 > 生活百科 > >

京東云TiDB SQL優化的最佳實踐( 二 )

生活百科


文章插圖
關注下圖的time變化，執行計劃由毫秒級變成了秒級的地方，由71ms變成了33s，所以瓶頸卡在（（m join d） join taskm）join taskd 這個地方，對應的SQL片段如下：
INNER JOIN taskdON taskd.no = d.no AND taskd.o_no = d.o_no AND taskd.d_no = d.d_no AND taskd.w_no = d.w_no AND taskd.g_no = d.g_no AND IF(NULL = d.MD5_VALUE, 1, d.MD5_VALUE) = IF(NULL = d.MD5_VALUE, 1, taskd.MD5_VALUE) AND taskd.yn = 0●優化思路1、首先觀察 explain analyze 結果 ， 看到慢在最內 3 層的 join 上，(m join d) join taskd；
2、對比 MySQL 的執行計劃 ， 發現 MySQL 最內的 3 層的 join 是 (m join d) join taskm, 所以把相關的3張表提取出來，修改其join順序；
3、修改順序后，join 的時間能減少但是和 MySQL差距還是很大，再次觀察，發現 taskd 上TiDB和MySQL使用的索引不一樣，所以使用了 use index 來強制TIDB走和MySQL相同的索引 。
案例二：表關聯的錯誤選擇導致SQL變慢的優化實踐場景：在MySQL運行時間毫秒級別 ， 在TiDB運行時間18S
在TiDB的運行時間及執行計劃

京東云TiDB SQL優化的最佳實踐

文章插圖
優化前后的執行計劃
京東云TiDB SQL優化的最佳實踐

文章插圖
優化后加了hint的SQL
京東云TiDB SQL優化的最佳實踐

文章插圖
● 優化思路：1. TiDB執行耗時 10+s 的原因是對 wps 表的估算不準確 ， 導致優化器認為 w表 和 p表 走 hash join 效率更高 ， 然后我們看到的執行計劃的主要耗時在 pri 表回表獲取數據的耗時較長 ；
2. w 表估算不準確的原因為TiDB 會把 w 的條件 有range scan 轉換點查，然后利用這個索引的統計信息去估算；
3. 點查估算是會利用對應的 CMSketch 去進行估算，結合 p 表數據量很大，根據經驗推測可能是 CMSketch 內部 hash 沖突導致 。
●案例一、二的延伸擴展：在SQL優化的工作中 ， 經常會通過加hint的方式改變SQL的執行計劃，從而達到了優化的目的 ， 但是缺點是對SQL進行了硬編碼，如果業務程序使用了ORM框架，SQL的改造難度會增加 。SQL Binding（SPM）則很好的解決了硬編碼的問題，通過SQL Binding，DBA可以在不改變SQL文本的情況下 ， 優化sql的執行計劃，從而達到優化的目標，從而使SQL優化變得更加優雅 。
京東云聯合 PingCAP 基于國內開源 NewSQL 數據庫 TiDB 打造的一款同時支持 OLTP 和 OLAP 兩種場景的分布式云數據庫產品，實現了自動的水平伸縮，強一致性的分布式事務 ， 部署簡單，在線異步表結構變更不影響業務，同時兼容 MySQL 協議，使遷移使用成本降到極低 。
作者：趙玉龍

推薦閱讀