問題
用 pt-table-checksum 時，會不會影響業務性能？
實驗
實驗開始前，給大家分享一個小經驗：任何性能評估，不要相信別人的評測結果，要在自己的環境上測試，並（大概）知曉原理。
我們先建一對主從：
然後用 mysqlslap一個持續的壓力：
開另外一個會話，將 master 上的 general log 打開：
然後通過 pt-table-checksum 進行一次比較：
查看 master 的 general log，由於 mysqlslap 的影響，general log 中有很多內容，我們找到與 pt-table-checksum 相關的線程：
將該線程的操作單獨列出來：
操作比較多，我們一點一點來說明：
這裡工具調小了 innodb 鎖等待時間。使得之後的操作，只要在 innodb 上稍微等待，就會馬上放棄操作，對業務影響很小。
另外工具調小了 wait_timeout 時間，倒是沒有特別的作用。
工具將隔離級別調整為了 RR 級別，事務的維護代價會比 RC 要高，不過後面我們會看到工具使用的每個事務都很小，加上之前提到 innodb 鎖等待時間調到很小，對線上業務產生的成本比較小。
RR 級別是數據對比的基本要求。
工具通過一系列操作，了解表的概況。工具是一個數據塊一個數據塊進行校驗，這裡獲取了第一個數據塊的下邊界。
接下來工具獲取了下一個數據塊的下邊界，每個 SQL都會 EXPLAIN，看一下執行成本，非常小心翼翼。
之後工具獲取了一個數據塊的 checksum，這個數據塊不大，如果跟業務流量有衝突，會馬上出發 innodb 的鎖超時，立刻退讓。
以上是 pt-table-checksum 的一些設計，可以看到這幾處都是精心維護了業務流量不受影響。
工具還設計了其他的一些機制保障業務流量，比如參數 --max-load 和 --pause-file 等，還有精心設計的數據塊劃分方法，索引選擇方法等。大家根據自己的情況配合使用即可達到很好的效果。
總結
本期我們介紹了簡單分析 pt-table-checksum 是否會影響業務流量，坊間會流傳工具的各種參數建議或者不建議使用，算命的情況比較多，大家都可以用簡單的實驗來分析其中機制。
還是那個觀點，性能測試不能相信道聽途說，得通過實驗去分析。
關於愛可生
愛可生成立於2003年，依託於融合、開放、創新的數據處理技術和服務能力，為大型行業用戶的特定場景提供深度挖掘數據價值的解決方案。
公司持續積累的核心關鍵技術，覆蓋到分布式資料庫集群、雲數據平臺、資料庫大體量運管平臺、海量數據集成於存儲、清洗與治理、人工智慧分析挖掘、可視化展現、安全與隱私保護等多個領域。
公司已與多個行業內的專業公司建立了長期夥伴關係，不斷促進新技術與行業知識相結合，為用戶尋求新的數據驅動的價值增長點。公司已在金融、能源電力、廣電、政府等行業取得了眾多大型用戶典型成功案例，獲得了市場的認可和業務的持續增長。