关于TiDB性能优化的一些思考

（转载公众号：晓磊聊DB）

为什么定性能优化这个主题？

写在TUG 企业行将走进 58 同城之前，作为TUG的华北区leader，在定这次企业行主题时，就想到TiDB性能优化这个大方向，因为在asktug网站的主题提问或者分享方案以及线下的交流中，听到不少关于TIDB性能优化的案例，一般都是基于一些“惨痛”的踩坑事故，分析问题现场，查看基于官方文档、Asktug论坛或者跟Pingcap技术专家交流后，定位问题，提供性能优化的方案，最后解决问题。这是大部分“性能优化”案例，其实背后都是TiDB运维人员一次次的事故Postmortem(PS:都是心酸泪啊)。

所以本次企业行邀请了58 同城、知乎、理想汽车、PingCAP 的技术专家将分享 TiDB 的性能优化实践。

我对优化的理解
其实作为数据库都离不开“优化”这个主题，优化的细分主题和主题的延伸都比较广阔，可以从2个大方面来拆分：基于层次的优化；基于场景的优化。

基于层次的优化
为什么叫基于层次的优化，因为从我看来，优化是一层层递进的，可以从：硬件、软件、SQL优化这3个层次来看。

1.硬件

• CPU：选配什么CPU，调整什么参数使得CPU发挥最大功效
• 网卡：千兆/万兆，之前使用MySQL就是千兆网卡，并且使用不到50%，你现在上线就用万兆？涉及网络方面的参数调优。
• 硬盘：SAS盘能玩TIDB么？sata SSD/Pcie-ssd如何配置，硬盘参数：IO调度，大页等
• 内存：如何配置TiDB的内存使用，关闭共享内存等等
  2.软件

    OS：

      1、操作系统的版本，其实主要是Linux的内核调优

      2、操作系统的参数？上面已经提到了。

TiDB集群参数：

• tidb：tidb的参数有调整过么？
• pd：PD的调度等参数
• tikv：tikv压缩，region size等参数？
• 动态调整，作用域(show variables)(edit config)等等。
• 调优
• 操作系统的参数？上面已经提到了。
  3.SQL优化：
• 从“根基”就要打好基础：涉及到建表，字段选择等
• 索引使用：索引的使用是数据库更古不变的优化项
• SQL改写：SQL的写法不同也会影响到性能，比如子查询改写
• 到解决方案时：sql binding
• 统计信息问题：TiDB 使用统计信息来决定索引的选择，大家也经常遇到统计信息不准导致的索引选择错误问题。
  基于场景的优化
  因为各个公司业务不同，需要优化的点也不同，所以可以细分成不同的场景，之前在asktug也写了不少优化的文章，比如在写冲入较高的场景下如何提升写入性能，还有不少读热点定位和解决的文章，所以从大的场景来看，可分为读热点优化，写热点优化，特定场景调优，可以看下面的思维导图： 

1.读优化：

• 读热点：这个读热点问题在asktug是很普遍的问题
• SQL执行计划稳定性问题
• Tiflash下推：有可能SQL中使用到tiflash没有下推的函数
• SQL延迟高：各种原因的“综合体”
• TiDB server OOM：大SQL导致内存使用过载，OOM kill
  2.写入优化：
• 写热点：这个写热点问题在asktug是很普遍的问题
• 悲观/乐观事务：之前我写过一篇文章
• 主键使用问题：自增主键 or auto random
• 没有主键：shardingrowbits
• 分布式事务：2PC or 异步提交(1PC)
  3.基于特定场景的调优：
• DDL执行过慢：一般新增字段比较快，添加索引很慢，如何加速？
• KV负载不均衡：PD调度参数了解下？
• OLAP SQL执行问题：JOIN+group by，MPP了解下？
• ETL场景：涉及批量的读写慢问题
• 限制大查询：kill SQL or 设定statement quota
  重点
  最后其实想表达的是：上面只是优化的一些思考，主要是抛出涉及“优化”这个主题可能涉及的问题和方向，不同人有不同的理解，可以多多交流，对于我的理解还请轻怕。