为什么定性能优化这个主题？
写在TUG 企业行将走进 58 同城之前，作为TUG的华北区leader，在定这次企业行主题时，就想到TiDB性能优化这个大方向，因为在asktug网站的主题提问或者分享方案以及线下的交流中，听到不少关于TIDB性能优化的案例，一般都是基于一些“惨痛”的踩坑事故，分析问题现场，查看基于官方文档、Asktug论坛或者跟Pingcap技术专家交流后，定位问题，提供性能优化的方案，最后解决问题。这是大部分“性能优化”案例，其实背后都是TiDB运维人员一次次的事故Postmortem(PS:都是心酸泪啊)。
所以本次企业行邀请了58 同城、知乎、理想汽车、PingCAP 的技术专家将分享 TiDB 的性能优化实践。
我对优化的理解
其实作为数据库都离不开“优化”这个主题，优化的细分主题和主题的延伸都比较广阔，可以从2个大方面来拆分：基于层次的优化；基于场景的优化。
基于层次的优化
为什么叫基于层次的优化，因为从我看来，优化是一层层递进的，可以从：硬件、软件、SQL优化这3个层次来看。
硬件
CPU：选配什么CPU，调整什么参数使得CPU发挥最大功效
网卡：千兆/万兆，之前使用MySQL就是千兆网卡，并且使用不到50%，你现在上线就用万兆？涉及网络方面的参数调优。
硬盘：SAS盘能玩TIDB么？sata SSD/Pcie-ssd如何配置，硬盘参数：IO调度，大页等
内存：如何配置TiDB的内存使用，关闭共享内存等等
软件
OS：
1、操作系统的版本，其实主要是Linux的内核调优
2、操作系统的参数？上面已经提到了。
TiDB集群参数：
tidb：tidb的参数有调整过么？
pd：PD的调度等参数
tikv：tikv压缩，region size等参数？
动态调整，作用域(show variables)(edit config)等等。
调优
操作系统的参数？上面已经提到了。
SQL优化：
从“根基”就要打好基础：涉及到建表，字段选择等
索引使用：索引的使用是数据库更古不变的优化项
SQL改写：SQL的写法不同也会影响到性能，比如子查询改写
到解决方案时：sql binding
统计信息问题：TiDB 使用统计信息来决定索引的选择，大家也经常遇到统计信息不准导致的索引选择错误问题。
基于场景的优化
因为各个公司业务不同，需要优化的点也不同，所以可以细分成不同的场景，之前在asktug也写了不少优化的文章，比如在写冲入较高的场景下如何提升写入性能，还有不少读热点定位和解决的文章，所以从大的场景来看，可分为读热点优化，写热点优化，特定场景调优，可以看下面的思维导图：
读优化：
读热点：这个读热点问题在asktug是很普遍的问题
SQL执行计划稳定性问题
Tiflash下推：有可能SQL中使用到tiflash没有下推的函数
SQL延迟高：各种原因的“综合体”
TiDB server OOM：大SQL导致内存使用过载，OOM kill
写入优化：
写热点：这个写热点问题在asktug是很普遍的问题
悲观/乐观事务：之前我写过一篇文章
主键使用问题：自增主键 or auto random
没有主键：shardingrowbits
分布式事务：2PC or 异步提交(1PC)
基于特定场景的调优：
DDL执行过慢：一般新增字段比较快，添加索引很慢，如何加速？
KV负载不均衡：PD调度参数了解下？
OLAP SQL执行问题：JOIN+group by，MPP了解下？
ETL场景：涉及批量的读写慢问题
限制大查询：kill SQL or 设定statement quota
重点
最后其实想表达的是：上面只是优化的一些思考，主要是抛出涉及“优化”这个主题可能涉及的问题和方向，不同人有不同的理解，可以多多交流，对于我的理解还请轻怕。下面是这次TUG-58企业行的邀请，大家积极报名参与下：
