作业帮 & TiDB 7.5.x 使用经验

2024-08-23
北京
本文字数：1329 字
阅读完需：约 4 分钟

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

近期在使用 TiDB 时遇到的一些小问题的梳理总结，大部分版本都在 6.5.6 和 7.5.2

1、limit 导致的扫描量过大的优化

研发定时任务每天需要扫描大量数据，到时机器网卡被打满，严重影响集群性能。这个 SQL 的主要问题在于：a. ha3data 是 text 字段

b. 虽然是 limit 1000 但是实际上扫描的量远超过 1000 条

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

复制代码

解决办法：1、将 utime 时间范围缩短，但是研发人员认为修改成本高 2、修改 tidb_opt_limit_push_down_threshold 的值大于 1000 第二种方法官方老师推荐不要直接修改优化器的参数，可能会遇到未知问题，影响其他 sql ，建议在语句里加 hint

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

复制代码

修改之后，网卡使用立即下降

2、为表增加 ttl 属性自动删除过期数据导致的 raft cpu 飙高

我们使用 7.5.2 版本的主要初衷是使用自动过期，可以让研发不用手动清理数据，但是在使用的时候注意两点 a. 尽量在业务低峰时段进行 ttl 的操作 (通过参数设置)

b. 调小 ttl 相关的参数

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 监控中可以看到有大量的 ttl qps，将 ttl 的运行时间调整成半夜时间范围后，raft cpu 使用率明显下降

3、表的自增 id 连续性问题的

业务反馈表的自增 id 不够连续，每次都是增加 2 个步长，研发人员担心涨的过快超过下游业务消费时出现类型溢出的问题，想要实现 mysql 那样的连续递增

解决办法：

为表增加 AUTO_CACHE_ID 注意：据社区小伙伴反馈，7.5.1 这个属性有 bug ，并且 7.5.1 还有 cdc 相关的配置不兼容 6.5.x 的 bug,需要升级到 7.5.2 之后, 但是 7.5.2 发现了在 fast-ddl 模式下增加索引卡住的情况https://asktug.com/t/topic/1030933

4、频繁删除数据导致越来越慢的问题

问题原因：在删除数据后有大量的过期版本，但是 rocksdb compact 不够及时，导致后续删除的时候会扫描大量的过期版本而越来越慢，key_skipped_count 会特别大解决办法：1、删除的时候尽量控制条件的范围比如使用 id 或者时间字段做小范围的限制 2、等待 8.x 版本的新功能每天增量 compact

发布于: 刚刚阅读数: 1

原文链接:【http://xie.infoq.cn/article/af3c387481ab2cdd1e8f77679】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

作业帮 & TiDB 7.5.x 使用经验

1、limit 导致的扫描量过大的优化

2、为表增加 ttl 属性自动删除过期数据导致的 raft cpu 飙高

3、表的自增 id 连续性问题的

4、频繁删除数据导致越来越慢的问题

TiDB 社区干货传送门

评论