作者：劉春雷
價值幾十萬的TiDB優化
--2021-06-12 劉春雷 首先請大家了解我這次成為了“标題黨”，違背了我每次的内容至上的追求；因為這次業務損失了幾十萬，是以就叫：價值幾十萬的TiDB優化
1、前言
58同城每年的年初為業務流量高峰，例如租房、找工作、本地服務等等，幾乎所有的業務都會瘋狂增長，對資料庫來說是個很大的挑戰。TiDB資料庫同樣壓力山大~
TiDB很多重要的業務，年前都優化過，擴容過，也回報給開發相關慢SQL、業務邏輯問題等，就是希望在年後能平穩度過業務高峰期。
然鵝，事與願違，面對全業務線的高峰，TiDB某重點業務出問題了：3月初某天，業務回報寫入慢，導緻部分訂單損失，價值幾十萬，情況萬分危急~
2、問題排查定位
【基礎資訊】：
TiDB版本：4.0.2
2.1、監控情況
監控資訊：可以從監控看出，SQL執行時間已經在1s-2s+ 了，但是沒有突增
業務損失原因：業務抛棄的時間門檻值是3s，即業務邏輯+SQL的整體時間超過3s ，此訂單就抛棄了，導緻了損失。
【TiDB監控】：
【系統監控】：
2.2、慢SQL量情況
DBA同樣排查慢SQL情況，發現慢SQL量在出問題的時間，沒有明顯增長很多，隻是增長了一點
注：中間的高峰為操作導緻，忽略
【慢SQL趨勢圖】：
【慢SQL量詳細】：
【超1.5s 慢SQL】：
超過1.5s的慢SQL資訊如下，這些可能導緻業務時間超3s，抛棄導緻損失~
【超1.5s慢SQL量詳細】：
2.3、慢SQL具體分析
發現量最大的慢SQL是節前1月份已經通知開發的慢SQL，開發沒跟進解決…導緻節後：業務流量增加的情況下，叢集寫入性能不佳。
總共2種慢SQL，分析可以添加一個聯合索引解決。之前問題為：查詢沒有覆寫到所有字段導緻性能差，進而影響了整個叢集的性能。
2.3.1、慢查詢SQL1
【問題SQL】:
SELECT COUNT(0) FROM xxx WHERE xx_date >= ‘xxx’ AND xx_date <= ‘xxx’ AND xxx_id = xxx AND xxx2_id = xxx AND xxx_type = 1 ;
【分析SQL量】：
select count(*),avg(Query_time),min(time),max(time),max(Query_time) from cluster_slow_query where time >=‘2021-03-04 00:00:00’ and time<=‘2021-03-04 23:59:59’ and Digest=‘xxx’;
【優化前執行計劃】：
執行計劃：發現掃描的行數比較多，且表的健康度不高,導緻執行計劃不正常，DBA嘗試analyze表解決。
【處理】：
analyze table xxx;
【analyze後續執行計劃】：
analyze表後，執行計劃算是正常了，掃描條數下降了，但是索引不是最優，還需要索引優化
【索引優化】：
添加索引： alter table xxx add index idx_xx(xx_id,xx2_id,xx_type,xx_date);
【添加索引後的執行計劃】 ：
2.3.2、慢查詢SQL2
SELECT * FROM xxx WHERE xx_date >= ‘xx’ AND xx_date <= ‘xx’ AND xx_id = xx AND xx_id = xx AND xx_type = 0 ORDER BY xx_date DESC LIMIT 0,400;
【分析SQL量】 ：
select count(*),avg(Query_time),min(time),max(time),max(Query_time) from cluster_slow_query where time >=‘2021-03-01 00:00:00’ and time<=‘2021-03-01 23:59:59’ and Digest=‘xx’;
【優化前執行計劃】：
【同樣添加索引後的執行計劃】：
2.4、執行索引優化
因表比較大，數量：分表128張，且白天要控制速度添加，減少對業務的影響，晚上适當加速添加
共計：
開始：2021-03-03 13:55:49
結束：2021-03-13 19:48:09
總共曆經： 10天+
2.5、索引優化後的效果
【監控情況】：
3、擴容
同時，出問題的當天，我們就對TiDB的資源進行了擴充，擴容TiDB Server 、TiKV Server。
但擴容是無法快速解決問題的，這個是TiDB後期可以考慮優化的事情，不像MySQL，我可以快速擴容從節點，來提升讀性能這樣；TiDB需要均衡好資料後，才能真正有性能提升。這點确實讓人頭疼~
【擴容詳細】：
3.3号13點左右開始進行擴容
擴容tikv 機器： 6台
擴容tidb機器： 4台+
目前均衡：
leader均衡 03-04 08:40 完成
region均衡： 03-10 10:00 完成
【監控情況】：
leader均衡很快，region均衡的時間比較長
4、參數調優
問題當天，官方就高優支援我們進行故障的處理與調優，給了一些調優的參數。這裡要重點表揚~官方服務實在太好！
4.1、參數調優及說明
【調優參數】：
server_configs:
tikv:
raftdb.defaultcf.force-consistency-checks: false
raftstore.apply-max-batch-size: 256
raftstore.apply-pool-size: 10
raftstore.hibernate-regions: true
raftstore.messages-per-tick: 1024
raftstore.perf-level: 5
raftstore.raft-max-inflight-msgs: 2048
raftstore.store-max-batch-size: 256
raftstore.store-pool-size: 8
raftstore.sync-log: false
readpool.coprocessor.use-unified-pool: true
readpool.storage.use-unified-pool: true
readpool.unified.max-thread-count: 12
rocksdb.defaultcf.force-consistency-checks: false
rocksdb.lockcf.force-consistency-checks: false
rocksdb.raftcf.force-consistency-checks: false
rocksdb.writecf.force-consistency-checks: false
server.grpc-concurrency: 8
storage.block-cache.capacity: 148G
storage.scheduler-worker-pool-size: 8
【參數詳細說明】：
4.2、修改參數效果
因為調整參數需要reload重新開機tikv執行個體，這樣影響比較大，如果出現性能不升反降，再調整回去，影響太大，是以我們先在其他叢集上進行測試，發現确實提升明顯，多數SQL執行時間都下降至少50%+ 。
于是我們在2021-03-16 20:53 開始調整參數，reload tikv， 21:06 完成，效果如下：
【TiDB監控】：
【SQL執行時間對比】：
【具體資料】：
5、資料清理
後期我們與業務溝通，之前遷移至TiDB為整個叢集遷移的，部分表不用，且占了很多的空間，于是我們也進行了資料清理，即不需要保留的資料及時清理掉，減輕叢集的壓力。
清理前： 23.7T
清理後： 14.2 T
磁盤降低： 9.5T ,占比： 40.08%
【清理資料後的SQL執行時間效果】：降低明顯
6、資源回收
優化後的叢集性能很好，但是TiKV機器比較多了，出于資源的考慮，我們回收了3台tikv server，回收後的性能也能很好的滿足業務。
【下線後的SQL執行時間】：
【磁盤資訊】：
總共 已用 占比
49.9T 14.6T 29.25%
7、總結
7.1、優化措施進度總結
此次事故，業務損失了幾十萬，算是一個深刻的教訓了，但是總結起來還是受益匪淺，希望給大家也看下。
反思：
- 重要的業務要定期檢視叢集狀态、性能
- 已經回報給開發的問題，要跟進優化落地，否則後面還是會發生問題
- 要多角度優化，不僅DBA叢集方面優化，業務也要在業務側進行優化
- 總結的參數，後續預設成為了新叢集的預設參數，老叢集調優也經常用到，多個叢集SQL執行時間的優化效果都超級好，大家可以按需測試
- DBA這邊暫時還沒做SQL執行時間的報警，後面會補充上
- TiDB如何快速通過擴容的方式提升性能，這個希望TiDB能做出來
-
表健康度影響SQL執行計劃，過低的表要定期analyze\
價值幾十萬的 TiDB優化 \