1、根据cluster_slow_query找到开销较大的sql分析优化可能性。
2、没有优化空间，就需要扩容。
还没用，么得优化的路子
每晚定时跑跑统计信息
把耗时sql找出来针对优化
慢SQL优化掉，基本上解决大部分问题
根据图形化界面分析功能，给出优化建议
初始情况下做好基本的硬件优化和sql层面，后期大多是慢sql层优化和数据设计优化
根据执行计划优化慢SQL，该加索引加索引。
- 慢查询
- 服务器性能
- 实例参数
- 业务优化
操作系统排查(网络、io、cpu、内存)是否有瓶颈
数据库的瓶颈主要包含sql、rpc调用、bug
【查询优化】通过分析业务需求和 SQL 执行计划，使用合适的索引、避免全表扫描、调整SQL语句等方式来提高查询性能。
【统计信息优化】定期收集统计信息并更新，使用多列统计信息以优化复杂查询的执行计划。
【硬件和网络优化】选择合适的硬件配置和网络带宽，如使用 SSD 存储、更大内存、更快网络等。
【TiDB 集群优化】根据实际业务需求，进行合理的 TiDB PD、TiKV、TiFlash 的配置和调整。
【数据库应用优化】利用缓存技术减少对数据库的访问，采用分表策略解决单表过大的问题，使用批量操作减少数据库交互次数。
索引是优化sql的核心
主要就是基于Dashboard定期排查慢查询和P99等抖动
硬件和参数基本规划好了之后就不动了，优化慢SQL解决90%以上问题
性能优化着是个非常大的课题。如果能找到性能问题出现在哪个地方就已经成功一半了。比如SQL慢的问题，如果能确定单次执行慢?还是大量类似的语句超常规执行造成整体的操作系统慢？ 如果确定是单个SQL慢，那么执行计划是否合理？慢在IO还是CPU？是缺少索引还是统计信息的问题？如果是IO问题， 如何收集系统的IO数据？是否单个磁盘IO慢还是整个系统IO慢？是否有硬件报警？
- 更换SSD，做好分区。
2.拆分大表
拆分sql，让数据库做擅长的事，计算交给应用
当然是让业务方优化sql了。
我们能做的就是根据业务类型调调tikv的线程池。
硬件提高IO。减少慢查询。上tiflash。
不同问题不同优化手段吧。
慢SQL那就优化SQL，
系统参数设置不当就调整参数，其实应该要具体问题具体分析。
不过大部分第一件时间是捞资源使用情况和慢SQL