作者： 18515065291 原文来源：https://tidb.net/blog/3ed4f9ff

价值几十万的 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

【最后 SQL 执行时间】