分区表全局索引，自动统计信息收集（最好是可以自动过滤blob字段，默认全字段，遇到blob会收不动）

tikv，tiflash都用不同的目录，根下的。

【最符合预期的功能有哪些】topsql 【哪些功能还需要继续改进】sql绑定执行计划 【哪些功能对你帮助不大】流量图

看日志报错，有启动时间超过pump的gc了

我用过6.5 版本的，edit-config 修改后reload是不会成功的。没使用过8.1，可能8版本不一样吧

https://docs.pingcap.com/zh/tidb/stable/deploy-and-maintain-faq#为什么修改了-tikvpd-的-toml-配置文件却没有生效 参考一下这个，永久修改要用pd ctl 。

1.当前使用的 TiDB 版本 6.5 2.启动强制主键参数sql_require_primary_key global级别开启后，session 级别可以关闭，业务在不知道的情况下做此类操作，会影响cdc同步。 3.其他反馈和建议。 lightning 工具也是会建的无主键表（不是导数的表，自身工具需要的）。

结果第一列为 audit-id tiup cluster audit |tail -10 继续执行指定的命令 tiup cluster replay 升级中，如果升级到一半失败，可以用这个方式继续执行，避免重复操作。

重启失败就调大一点，是不是pd那里卡住了？

强制切leader的，可以加快很多。不用等都迁移完。有说明的，默认比较长 tiup cluster upgrade --help –transfer-timeout uint Timeout in seconds when transferring PD and TiKV store leaders, also for TiCDC drain one capture (default 600)

–transfer-timeout=15 加一个这个参数可以加快升级速度，业务会有抖动

好吧，tidb server 日志一般会记录sql报错的语句的，可以留意下。

show config where name like ‘%reserve-space%’; 用这个看下。

就是所有tikv需要磁盘容量大小一致，这影响很多调度打分

可以检查下两个库的tso时间是不是一致的？

加hint ，用慢的sql参数带入，看看快不快就知道了。有可能是数据倾斜导致的不同执行计划。

磁盘使用率很高的情况，会影响性能，tikv的目录是不是存在大小不一致的情况。不然调度应该是不会停止的。磁盘大小打分，没有单独调的话，应该是一致的。 如果想用的更多，这个保留文件的参数可以调小点。 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#reserve-space 混部的情况要看下这个参数。 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#capacity-1

tidb日志应该有记录报错的语句

莫得分，分不够