tidb性能调优参数整理

持续整理中。。。。

---------创建索引 -------
动态参数
set global tidb_ddl_reorg_worker_cnt =4 创建索引回填数据的并发度（如果业务繁忙要调小）（调大，加快索引的创建）
set global tidb_ddl_reorg_batch_size=256 如果与线上业务冲突，调小（调大，加快索引的创建）

-----请求数量限制-----
tidb_store_limit :控制同时发往一个 tikv 节点的请求数量，避免并发请求多对TIKV 造成压力
tidb的: token-limit :用于流量控制，配置可以同时执行请求的session数量（多的阻塞），避免 并发请求过多造成tidb-server 资源耗尽，服务无法响应
tidb_retry_limit : 控制乐观锁事务的重试次数

--------存储 ----------------
PD调度有关的参数
balance-leader-scheduler 保持不同节点的leader 均衡
balance-region-scheduler 保持不同节点的peer均衡
hot-region-shceduler 保持不同节点的读写热点region均衡

----- 扩容 TiKV 时调整的参数 -------
leader-schedule-limit 控制 Transfer Leader 调度的并发数 （20220111扩容时 4改 24 ）
region-schedule-limit 控制增删 Peer 调度的并发数 （20220111扩容时值8 改为 64 )
replica-schedule-limit 同时进行 replica 调度的任务个数。默认：64 （20220111扩容时值8 改为4 【任务竞争】，复制时调大【比如store节点故障后补副本】，能同时一起往空的上走 ）
max-snapshot-count 每个 Store 允许的最大收发 Snapshot 的并发数，调度受制于这个配置来 防止 抢占 正常业务的 资源。
默认: 3 （20220111扩容时 5改 10 ）当需要加快补副本或 balance 速度时可以调大这个值。
max-pending-peer-count
控制单个 store 的 pending peer 上限，调度受制于这个配置来 防止 在部分节点 产生大量日志落后的 Region 默认：16 （20220111扩容时 16改 32 ）需要加快补副本或 balance 速度可以适当调大这个值，设置为 0 则表示不限制。

------------ tikv 写入参数优化 ----------------
scheduler-worker-pool-size [grafana 监控 tikv details --> thread cpu --> scheduler worker CPU 的利用率很高 ，则加大此值 ]
store-pool-size 重点 store-max-batch-size raft-max-inflight-msgs
apply-pool-size 重点 apply-max-batch-size
grafana 监控 tikv details —>thread cpu —> scheduler worker cpu
raft store cpu
async apply cpu
—>store -->storage async write duration
—>raft io —> commit log duration

------------ 读取 参数优化 ----------------
v5.0以上:
grafana监控 tikv details —> thread cpu —> unified read pool cpu 高，说明所有线程跑满了，调大参数 readpool.unified.max-thread-count
—> 上否，则 coprocessor overview/detail 查看参数 coprocessor handle 和 wait duration 高，可能 大范围扫描、请求不均衡
线程池配置过小 、 执行计划异常
请求不均衡 可能是热点，所有的读都集中在某几个region, 调大参数 split.qps-threshold (某个regiond的qps达到一定的阈值，自动打散到其它的region中 ) split.byte-threshold
—>上否 则 block cacke命中率 grafana 监控 tikv-details -->rocksdb kv —>block cache hit 高，则调整storage.block-cache.capacity （整个tikv内存的 45% --60%，太多了可能出现out to memory,其它没内存了 ）
v4.0以下老版本：
点查： storage read pool cpu （都在 tikv details —> thread cpu）
非 点查： coprocessor cpu

----------- split 大表 时调整参数 ----------------
“split-merge-interval”: “1h0m0s” 控制对同一个 Region 做 split 和 merge 操作的间隔，即对于新 split 的 Region 一段时间内不会被 merge。
默认: 1h ,split 大表时调大此值 ，避免在split的过程中merge

--------- write stall ----------------
内存 ： memtable [参数 write-buffer-size ] —> immutable memtable 达到 max-write-buffer-number的值【不宜过大，机器重启后因为重构数据会启动时间很长 】后 写入磁盘
磁盘 ： level 0 参数 level0-file-num-compaction-trigger 达到此值后向level1 compation
level0-slowdown-writes-trigger
level0-stop-writes-trigger
其它 compression-per-level

------------slow query ------
是不是读取数据的热点
grafana --> tikv details —> coprocessor detail —> handle duration 处理的时候产生的热点，延迟过高，可能 执行计划不合理（比较大 全表扫描或索引不合适）
—>wait duration coprocessor还没执行，在等待 (可能是 小表读热点[获得不到资源]，索引热点，CPU资源不足 )
—> storage duration