前言

距离上一篇文章已经过去半个月了，中间这两周呢，上上周在解决项目的线上问题，一直在改BUG，这个比较要紧，因为我上周休假了，要保证假期的时候没啥问题。前两篇都是讲了Flink的遇到的线上问题和对应的解法，留下了一些问题，比如Flink的学习和监控部分，我还是没找到好的方法精进一下，可惜。上周休假中，被拉起来加班，哎，紧急线上问题，搞了一晚上，周日上班还得接着弄，真的惨。可预见的是短期内，会投入大量的时间在已上线的项目上，毕竟是核心项目，被投诉了还是挺刺激的。数据同步的问题可能暂时就搁置了，没办法，好像最近也没人推进了，在项目线上问题彻底闭环之前我很难全身心投入解决这个问题。但是TIDB既然花了好几天研究，这个功夫也不能白费，哪怕没彻底解决问题，但是这个经历还是蛮重要的，所以还是记录一下。

尝龟姿势

继ElasticSearch之后找到第二个文档写的超级无敌棒的大型中间件，TIDB-官方文档，完全可以通过阅读文档了解大部分的知识点，按照左侧栏一篇篇阅读即可，注意左上角要选版本号，不同版本间文档会有少量差异。我对于新事物的学习通常是视频->文档->图解->实践->总结这样一条通路。具体一点就是通过视频去培养兴趣，找一个说话有意思的视频，先1.5倍速挂起来，了解一个大概，通过视频实在是太容易分散精力，所以倍速或者跳过挑重点看就行，主要是形成一个大体的认知。文档自然是首推官方文档，类似ES、Flink、TIDB这种都是必看的，除此之外视频配套的文档也得好好看看，有的讲得还是不错的，特别是大众课程。图解这块的话，重点搜罗下有没有大神图解以及博客之类的东西，对自己感兴趣的部分做一个深入的理解。实践部分，肯定得动手，无论是demo还是项目都要操作一下，因为有太多问题是只有实操的时候会遇到。解决问题的话，大众中间件推荐搜索博客解决，顺带还能了解一些细节，小众中间件推荐自带社区或者Github的Issue处搜索，比如TIDB自带的社区asktug.com/，比较活跃，有很多问题的解法，这种藏得深的搜索引擎权重太低，但往往这种地方才有解决方法，裂开。最后总结的话，就是像我这样输出几篇文档，强化一下自己的认知，温故知新。

我自认为对新事物还是有较强的接收能力，毕竟老是被赶鸭子上架，习惯了也有自己的一套方法论。当然快不一定好，及时总结才是神之一手，好记性不如烂笔头，隔了两周再回顾，得亏我之前记的有零零散散的知识点，还能辅助我回忆一下。接下来就直接开始，再爬一次长城，坐好了，开车了。

RE0

我是带着线上问题，也就是数据同步慢的问题来看TIDB的官方文档，一切以解决问题为目的来看文档。对了，我首先看了官方推荐的三篇文章，三篇文章了解 TiDB 技术内幕 – 说存储，这三篇文章都不长，加起来不到二十分钟就能看完，基本上对TIDB就是有一个大致的了解。官方文档可以一篇篇去读，讲得很细，有图有案例有代码，想对数据库有了解的一定要看，分布式和数据库的架构设计都是触类旁通的，遇到这种讲得细的一定要跟着官方好好理解。官方文档我现在还没看完，实在是太丰富了，我只是针对我遇到的问题，挑了重点去看。

加加加索引

从TIDB DASHBOARD里的慢查询一栏，找这个库下面的慢SQL，可以看到这个表出现了严重的性能问题。大量的UPDATE语句来源于Flink的数据同步，这里是根据某个唯一值进行更新，所以初步判断是没加索引导致的。

点进详情记录一下TIDB节点地址留作后用，进一步看细节

到这一步就很明显，TiKV处理慢，这里参考官方文档分析慢查询一文进行排查，点开执行计划。

可以很明显地看出是全表查询，没有任何索引，这肯定是不对的，到这一步基本上问题就锁定了。

该表数据量大，4.5KW，如果没法看TIDB看板的，也可以通过Explain Analyze查询，同样也能看出问题来。其他类似的表，我也都加上了索引，此类问题就算是解决了。这里还需要注意的是TIDB不支持在Navicat客户端进行多列索引操作，但是可以通过SQL添加多列索引，而且官方推荐也是通过SQL添加TIDB-索引。

TIKV写入慢

在找慢查询的时候，无意间发现这个问题，查了下官方文档

但是我查了下TIDB自带的Grafana看板，发现又没有问题

因此判断应该不是这个问题，在定位这个问题的时候，学习了下官方的一些TIKV相关文档，我们可以手动调整一些配置。

以上是我TIDB的整体配置，比较标准的节点分布。TIKV的配置描述看官网的，大部分都不用调整，TiKV 配置文件描述，线程池有一些需要按照机器配置进行调整，TIKV线程池调优。TiKV 从 v6.3.0 开始支持根据统一读线程池 (UnifyReadPool) 的 CPU 利用率自动动态调整线程池的线程数量，可以通过配置 readpool.unified.auto-adjust-pool-size 开启此功能。对于重读并且峰值 CPU 利用率超过 80% 的集群，建议开启此配置。TIDB的修改配置方法，按照官方文档说明的来，有些配置需要重启，但是我们用到的大部分基本都可以热更新，TIDB在线修改配置。比如上面这个这个配置，可以通过如下SQL进行修改。

SHOW config WHERE `type` = 'tikv' AND `name` LIKE '%readpool.unified.auto-adjust-pool-size%';
SET config tikv `readpool.unified.auto-adjust-pool-size`= 'true';

写写冲突

因为prewrite阶段停留太长时间，怀疑有写写冲突，按照乐观事务模型下写写冲突问题排查的官方文档进行排查，通过 TiDB 监控面板中 KV Errors 监控栏中 KV Backoff OPS 监控指标项，查看 TiKV 中返回错误信息的数量。txnlock 表示集群中存在写写冲突，txnLockFast 表示集群中存在读写冲突。图里没有，说明没冲突，按理说也应该是这样，因为数据同步的Flink代码在修改后理论上不存在写写冲突的可能。

TIKV热点问题

因为我主观臆断的问题原因是TIKV写入慢，所以我就想到会不会是热点问题。导致某个节点过慢，因为我从TIDB看板上有看到几秒的延迟。TiDB热点问题处理，按照官方文档的说法开始定位问题。

通过下图监控可以看出，CPU使用均衡，没有个别节点突出的情况，也就是说没有写热点问题

读写延迟

找来找去，发现官方文档还有这个读写延迟增加，看了下监控，也没问题

差别不大说明也没啥延迟，我真的懵了

微醺码头

虽然暂时没能定位出问题，但是在解决问题的过程中还是学到了不少东西，有些是之前在使用New Sql时没有注意到的，这里分享一下。

索引添加优化

我在给一张大表加索引的时候发现的。起因是MTL_SYSTEM_ITEMS_B这张表400字段，66W数据，通过SQL加索引发现超过2小时仍然没有成功，当时都懵了，咋能这么慢。然后用加索引慢这个关键词在官方文档搜索，发现添加索引性能最佳实践，这样一篇文章。官方的意思是，为了减少对线上业务的影响，添加索引的速度会比较保守，但是也提供了加速的手段。默认配置如下

如下调整即可，别忘了最后调回去，不然影响线上服务。

SHOW VARIABLES LIKE '%tidb_ddl_reorg%';
//当添加索引的目标列仅涉及查询负载，或者与线上负载不直接相关时，可以适当调大上述变量来加速添加索引：
SET @@global.tidb_ddl_reorg_worker_cnt = 16;
SET @@global.tidb_ddl_reorg_batch_size = 4096;
//当添加索引操作的目标列被频繁更新（包含 UPDATE、INSERT 和 DELETE）时，调大上述配置会造成较为频繁的写冲突，使得在线负载较大；同时添加索引操作也可能由于不断地重试，需要很长的时间才能完成。此时建议调小上述配置来避免和在线业务的写冲突
SET @@global.tidb_ddl_reorg_worker_cnt = 4;
SET @@global.tidb_ddl_reorg_batch_size = 256;

不过说真的，这配置一调，是真的快啊，我都没想到能到秒级。

干掉SET autocommit语句

我是在TIDB官方社区查问题的时候，无意间发现了这篇帖子，发现从MySQL遗留下来的配置竟然会影响TIDB的性能，虽然我之前在TIDB官方文档看过那个配置，但是万万没想到会有这样的影响。大量 SET autocommit 导致的 TiDB Server CPU 高案例，我在TIDB看板中筛选了SET语句后发现真的有很多这样的语句

解决方案其实官方文档我看过，写得很清楚

最后我总结的常用配置是这样的，前面两个是批量有关的，后两个和超时时间相关。

jdbcUrl=jdbc:mysql://url:port/table?rewriteBatchedStatements=true&allowMultiQueries=true&useConfigs=maxPerformance&useServerPrepStmts=true&connectTimeout=300000&socketTimeout=600000

排查SQL性能问题

精细查询就用这个利用Statement Summary排查SQL性能问题，但是有图形化的我觉得更方便，而且V6.5的看板这里面真的够全了

写在最后

中间有部分我写的很简略，因为官方文档写得够详细，我再涂抹一下显得画蛇添足，索性就配了下图，说实话就是偷懒啦。上周休了三天假，回了趟老家，算是一周小长假，租房遇到了些不愉快的事情，但是解决了。放假中途遇到生产事故，加了一晚上班解决。假期如何呢？见到家人总是开心的，我个人也有些放松了，所以摸了一周，说好的更新也没有，学习也没有。最近想了很多事情，浅浅的想了一下，关于未来，学习还是继续，提升自己才是硬道理。

朋友今天不开心，让我讲笑话，我本来想抖个包袱，结果她接不上，可惜，于是发了一堆乐子。最近大家可能情绪都比较低落吧，说实话，我自己也是这样。有个朋友在上海刚刚毕业，迎接工作，哈哈，比起我工作的时候，现在可能才是真的噩梦开局吧。我老弟马上结束实习了，他985毕业，我倒是不担心他找工作，只是希望他能找个能力范围内最好的，现在环境不咋滴，希望大家都能过得好。最后的最后，再次重申我的人生信条，我要让这痛苦压抑的世界绽放幸福快乐之花，向美好的世界献上祝福！！！