作者： 是我的海 原文來源： https://tidb.net/blog/5f9784d3

近期在使用 TiDB 時遇到的一些小問題的梳理總結(jié)，大部分版本都在6.5.6和7.5.2

1、limit 導致的掃描量過大的優(yōu)化

研發(fā)定時任務每天需要掃描大量數(shù)據(jù)，到時機器網(wǎng)卡被打滿，嚴重影響集群性能。 這個 SQL 的主要問題在于： a. ha3data 是text 字段

b. 雖然是 limit 1000 但是實際上掃描的量遠超過1000 條

SELECT utime, ha3Data  FROM  tblAdxxxx  WHERE  utime <= 1718804236  AND utime >= 1
AND (deleted = 0)  ORDER BY  utime DESC  LIMIT  1000

解決辦法： 1、將utime 時間范圍縮短，但是研發(fā)人員認為修改成本高 2、修改tidb_opt_limit_push_down_threshold 的值大于1000 第二種方法官方老師推薦不要直接修改優(yōu)化器的參數(shù)，可能會遇到未知問題，影響其他sql ，建議在語句里加hint

SELECT  /*+ SET_VAR(tidb_opt_limit_push_down_threshold=2000) */   utime,   ha3Data FROM

修改之后，網(wǎng)卡使用立即下降

2、為表增加ttl 屬性自動刪除過期數(shù)據(jù)導致的raft cpu 飆高

我們使用7.5.2 版本的主要初衷是使用自動過期，可以讓研發(fā)不用手動清理數(shù)據(jù)，但是在使用的時候注意兩點 a. 盡量在業(yè)務低峰時段進行ttl 的操作(通過參數(shù)設置)

b. 調(diào)小ttl 相關(guān)的參數(shù)

MySQL [(none)]> show variables like '%ttl%';
+-----------------------------------------+-------------+
| Variable_name                           | Value       |
+-----------------------------------------+-------------+
| tidb_ttl_delete_batch_size              | 100         |
| tidb_ttl_delete_rate_limit              | 0           |
| tidb_ttl_delete_worker_count            | 2           |
| tidb_ttl_job_enable                     | ON          |
| tidb_ttl_job_schedule_window_end_time   | 07:23 +0800 |
| tidb_ttl_job_schedule_window_start_time | 23:11 +0800 |
| tidb_ttl_running_tasks                  | -1          |
| tidb_ttl_scan_batch_size                | 300         |
| tidb_ttl_scan_worker_count              | 2           |
+-----------------------------------------+-------------+

從tikv-details 的grpc 監(jiān)控中可以看到有大量的ttl qps， 將ttl 的運行時間調(diào)整成半夜時間范圍后，raft cpu 使用率明顯下降

3、表的自增id 連續(xù)性問題的

業(yè)務反饋表的自增id 不夠連續(xù)，每次都是增加2 個步長，研發(fā)人員擔心漲的過快超過下游業(yè)務消費時出現(xiàn)類型溢出的問題，想要實現(xiàn)mysql 那樣的連續(xù)遞增 解決辦法：

為表增加AUTO_CACHE_ID 注意：據(jù)社區(qū)小伙伴反饋，7.5.1 這個屬性有bug ，并且7.5.1 還有cdc 相關(guān)的配置不兼容6.5.x 的bug, 需要升級到7.5.2 之后, 但是7.5.2 發(fā)現(xiàn)了在fast-ddl 模式下增加索引卡住的情況 https://asktug.com/t/topic/1030933

4、頻繁刪除數(shù)據(jù)導致越來越慢的問題

問題原因： 在刪除數(shù)據(jù)后有大量的過期版本，但是rocksdb compact 不夠及時，導致后續(xù)刪除的時候會掃描大量的過期版本而越來越慢，key_skipped_count 會特別大 解決辦法： 1、刪除的時候盡量控制條件的范圍比如使用id 或者時間字段做小范圍的限制 2、等待8.x 版本的新功能每天增量compact