wordpress 編輯器 視頻教程?hào)|莞seo優(yōu)化方案
作者： 是我的海 原文來源： https://tidb.net/blog/5f9784d3
近期在使用 TiDB 時(shí)遇到的一些小問題的梳理總結(jié)，大部分版本都在6.5.6和7.5.2
1、limit 導(dǎo)致的掃描量過大的優(yōu)化
研發(fā)定時(shí)任務(wù)每天需要掃描大量數(shù)據(jù)，到時(shí)機(jī)器網(wǎng)卡被打滿，嚴(yán)重影響集群性能。 這個(gè) SQL 的主要問題在于： a. ha3data 是text 字段
b. 雖然是 limit 1000 但是實(shí)際上掃描的量遠(yuǎn)超過1000 條 
SELECT utime, ha3Data FROM tblAdxxxx WHERE utime <= 1718804236 AND utime >= 1
AND (deleted = 0) ORDER BY utime DESC LIMIT 1000
解決辦法： 1、將utime 時(shí)間范圍縮短，但是研發(fā)人員認(rèn)為修改成本高 2、修改tidb_opt_limit_push_down_threshold 的值大于1000 第二種方法官方老師推薦不要直接修改優(yōu)化器的參數(shù)，可能會(huì)遇到未知問題，影響其他sql ，建議在語句里加hint
SELECT /*+ SET_VAR(tidb_opt_limit_push_down_threshold=2000) */ utime, ha3Data FROM
修改之后，網(wǎng)卡使用立即下降 
2、為表增加ttl 屬性自動(dòng)刪除過期數(shù)據(jù)導(dǎo)致的raft cpu 飆高
我們使用7.5.2 版本的主要初衷是使用自動(dòng)過期，可以讓研發(fā)不用手動(dòng)清理數(shù)據(jù)，但是在使用的時(shí)候注意兩點(diǎn) a. 盡量在業(yè)務(wù)低峰時(shí)段進(jìn)行ttl 的操作(通過參數(shù)設(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 的運(yùn)行時(shí)間調(diào)整成半夜時(shí)間范圍后，raft cpu 使用率明顯下降 
3、表的自增id 連續(xù)性問題的
業(yè)務(wù)反饋表的自增id 不夠連續(xù)，每次都是增加2 個(gè)步長(zhǎng)，研發(fā)人員擔(dān)心漲的過快超過下游業(yè)務(wù)消費(fèi)時(shí)出現(xiàn)類型溢出的問題，想要實(shí)現(xiàn)mysql 那樣的連續(xù)遞增 
解決辦法：
為表增加AUTO_CACHE_ID 注意：據(jù)社區(qū)小伙伴反饋，7.5.1 這個(gè)屬性有bug ，并且7.5.1 還有cdc 相關(guān)的配置不兼容6.5.x 的bug, 需要升級(jí)到7.5.2 之后, 但是7.5.2 發(fā)現(xiàn)了在fast-ddl 模式下增加索引卡住的情況 https://asktug.com/t/topic/1030933
4、頻繁刪除數(shù)據(jù)導(dǎo)致越來越慢的問題
問題原因： 在刪除數(shù)據(jù)后有大量的過期版本，但是rocksdb compact 不夠及時(shí)，導(dǎo)致后續(xù)刪除的時(shí)候會(huì)掃描大量的過期版本而越來越慢，key_skipped_count 會(huì)特別大 解決辦法： 1、刪除的時(shí)候盡量控制條件的范圍比如使用id 或者時(shí)間字段做小范圍的限制 2、等待8.x 版本的新功能每天增量compact