【常见错误】
information_schema.tables.data_length 记录的大小和 TiKV 监控面板上的 store size 不一致
【原因】
因为两者计算的角度不一样。information_schema.tables.data_length 是通过统计信息（平均每行的大小）得到的估算值。TiKV 监控面板上的 store size 是单个 TiKV 实例的数据文件（RocksDB 的 SST 文件）的大小总和。由于多版本和 TiKV 会压缩数据，所以两者显示的大小不一样。
【解决方法】
根据自己的需要，两种方法同时参考，做大概的估算值。
暂时还没用过
Web界面的集群运维工具呢？
赚积分
【常见问题】
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 9,303 milliseconds ago. The last packet sent successfully to the server was 9,303 milliseconds ago.
【原因】
应用方的数据库连接有效期时间，大于数据库自己设置的有效期
【解决方案】
一、修改druid配置（如果使用druid的话）
spring.datasource.druid.validationQuery=select 1
spring.datasource.druid.testWhileIdle=true
spring.datasource.druid.testOnBorrow=true
spring.datasource.druid.testOnReturn=true
PS.此方案对性能会有一定影响
二、修改数据库连接配置
在数据库连接上，加“&autoReconnect=true&failOverReadOnly=false”配置
三、修改数据库连接有效时间
在数据库配置上设置，把数据库连接有效时间设置长一点，比如设置12小时或者24小时
TIKV server is busy，通常是由于tikv负载过高或网络负载打满导致的，可由监控确认后增大网络带宽或者扩容tikv节点解决
业务不多但负载很高，某些时候看会造成某名奇妙的慢sql
排查：
1.查看analyze的配置
2.查看analyze的执行状态
3.查看涉及到的慢查询的表的健康度
解决：
如果是有频繁不成功的analyze则通过手动analyze执行
如果是频繁analyze导致的负载高，则调整analyze的时间
如果是有大表analyze执行缓慢，则通过脚本定时手动analyze
【常见问题】
tikv节点日志庞大占用了硬盘百分之80的容量，修改了日志保留策略，删除了日志，一段时间后无写入报错硬盘无可用空间，结果df -Th 查询 空闲很多
【原因】
df -Th 查询还有百分之50的空间可用，d f -i 查询发现inode 使用百分之100.，是因为上此删除日志的时候没有释放掉inode
【解决方案】
停止该节点重启后完全释放。
1、某sql查询时出现 other error for mpp stream 报错时，
[解决方法]：set @@session.tidb_allow_mpp=0;
2、dashboard报错：error.pd.client_request_failed: Request failed with status code 500 from PD API: “[PD:cluster:ErrNotBootstrapped]TiKV cluster not bootstrapped, please start TiKV first”
[解决方法]：
切换dashboard地址，模拟重启dashboard
tiup cluster display tidb-app --dashboard #查看现使用的地址
tiup ctl:v5.1.1 pd -u http://192.168.10.51:2379 config set dashboard-address http://192.168.10.52:2379 #切换51到52
tiup ctl:v5.1.1 pd -u http://192.168.10.52:2379 config set dashboard-address http://192.168.10.51:2379 #切回
3、group by提示 only_full_gruou_by
[解决方法]：set global sql_mode=‘STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION’;
问题：多表连接时，发现 SQL 关联顺序和预期不一致，导致查询较慢
原因：TiDB 表关联默认采用 Join Reorder 算法
解决方案：可采用 STRAIGHT_JOIN 指定关联顺序
文章：专栏 - 一次多表关联顺序的慢查询——TiDB 关联特性 | TiDB 社区
文档：https://docs.pingcap.com/zh/tidb/stable/join-reorder#join-reorder-算法简介
问题：
以前用的4.0的版本，执行 LOAD DATA 不报错，升级5.0+版本后，LOAD DATA 报错
ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058
原因：
在 TiDB 的早期版本中，LOAD DATA 语句每 20000 行进行一次提交。新版本的 TiDB 默认在一个事务中提交所有行。从 TiDB 4.0 及以前版本升级后，可能出现 ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058 错误。
解决方法：
要解决该问题，建议调大 tidb.toml 文件中的 txn-total-size-limit 值。如果无法增加此限制，还可以将 tidb_dml_batch_size 的值设置为 20000 来恢复升级前的行为。
[常见错误]
tiup在线升级tidb部件失败，显示timeout
[解决方法]
1数据库系统手动重启。
2网络拥塞，手动调整宽带，错峰升级。
3修改配置
加减节点时候报错。
清理tombstone的节点
1.问题:利用可视化工具复制其他数据库的数据到tidb，报错事务太大同步失败
解决方法:调大tidb的txn-total-size-limit参数，因为此参数默认1G，同步表稍大就会报错
2.问题:k8s部署tidb，tikv经常oom导致重启
解决方法:修改tikv的storage.block-cache.capacity参数，因此参数默认设置为内存的45%，但是k8s上默认的是物理机的45%，一台物理机上有太多的pod，很容易内存oom重启，顾可以设置为单pod的45%
[常见问题]
版本v6.1 .20亿大表增加索引，时间过长,无法接受，甚至因为GC 导致增加索引失败。
[解决方法]
升级成v6.5版本，在增加索引性能上快10倍不止。快速增加索引。从低版本需要注意参数控制
暂时还没有应用过，先学习一下
我觉得还是热点问题应该是最常见的，最容易犯的。
在创建表设计表的初期，要考虑进去热点问题，
还有一个锁的问题，尽量业务设计的时候避免频繁竞争锁，等待锁的相关问题。
对了 还有就是oom问题。
记得设置相关sql 限制好内存使用，不然oom问题很头疼。
【常见错误】
dm数据同步提示：mydumper/dumpling runs with error, with output (may empty): “RawCause”: “invalid connection”,
【原因】
集群压力过大，并非数据库连接问题
【解决方法】
分小批批执行
