大家好，我是架構擺渡人。這是實踐經驗系列的第九篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收穫，還請分享給更多的朋友。
Mybatis是我們經常用的一款運算元據庫的框架，它的外掛機制設計的非常好，能夠在很多需求場景下派上用場。如果你還沒用過Mybatis的外掛（Mybatis 外掛實際是一種攔截器），那麼需要仔細閱讀這篇文章。
SQL監控埋點
說句大實話，大部分效能問題都發生在儲存層。當然對於優化我們需要有足夠的樣本，這些樣本也就是慢SQL。資料庫本身就有慢SQL的日誌，但不方便我們跟具體的介面和trace進行關聯。
如果要跟trace進行關聯那麼就必須自己進行埋點上報效能資料，像我們之前用Cat做監控的時候，就是基於Mybatis的外掛進行埋點，這樣可以在Cat中看到每次請求下執行了哪些SQL，以及SQL的執行時間。
SQL校驗
如果你們的表做了水平拆分，也就是分庫分表。當然有可能是用開源框架實現的，也有可能是自研的框架。對於SQL的寫法沒有過多要求，但是如果是分庫分表，而你的查詢語句中沒有帶分片的欄位，這個時候一般都是會進行所有表的查詢，然後合併結果返回。
假如你想打破這個規則，查詢的SQL中必須帶分片的欄位，否則就直接報錯。當然可以對你們的分庫分表框架進行改造，如果是開源的改起來比較麻煩，那是否可以簡單點實現呢？
可以的，答案就是用Mybatis外掛進行擴充套件，拿到執行的SQL進行分析，然後做校驗。
SQL改寫
SQL改寫相對來說用的比較少，主要是改寫是個很危險的事情，稍有不慎，線上就要炸鍋了。那麼改寫會有哪些場景下需要呢？
之前有遇到過的場景就是，我們接了一個新的分庫分表的框架，老框架是支援分表場景下update分片欄位的。比如你user表的分片欄位是id，那麼update語句中可以帶上這個id，只不過值還是原來的，不影響資料，這種也經常會在用一些自動生成SQL的場景下會有。
自從接了新框架後，對SQL更新有要求啦，分片欄位是不允許更新的，不能出現在update的SQL中，如果有就直接報錯。所以這個時候改寫SQL就排上用場了，當然為了穩定性，我們還是採用了最原始的方式，將所有SQL都改了一遍。
SQL中透傳資訊
SQL中透傳資訊這個很實用，問題在於透傳的資訊給誰使用呢？
其實這個要歸根於你們有沒有使用Proxy方式的分庫分表中介軟體，如果有的話就需要透傳資訊。
比如讀寫分離場景，Proxy怎麼知道你的SQL要走主庫還是走從庫呢？
比如在做壓測的時候，Proxy怎麼知道你的SQL要走正常庫還是影子庫呢？當然這個你也可以把影子庫控制放在客戶端。
那麼如何通過SQL進行資訊透傳呢？如下：
/*master:true*/ SELECT * FROM table
其實就是在SQL的前面加一些特殊的資訊，然後中介軟體去解析做對應的處理。