1、 [FAQ] Error 9007: Write conflict
集群压力过大也可能出现（3.0.0 有 bug 导致conflictCommitTS = 0），可以通过以下监控项来定位是否是事务冲突导致的：
- TiDB 面板中 kv retry
- TiDB 面板中 LockResolve
- TiDB 面板中 kv backoff count
- 参考官方文档 写写冲突 解决办法
2、[FAQ] Txn(Mvcc(TxnLockNotFound
查看提交间隔：./pd-ctl tso [start_ts] & ./pd-ctl tso [commit_ts] 是否太久根据报错信息查找对应的 SQL 信息，确认是否是 SQL 执行时间太久，对问题 SQL 进行优化
3、 [FAQ] tikv aborts txn: Txn(Mvcc(PessimisticLockNotFound
这一机制在 3.0.6 or 3.0.7 会调整：
1. ttl 会固定在 20s，不能调整
2. txn heartbeat 会自动更新事务的 ttl，保证第二个事务不会将第一个事务的锁清理掉，模拟类似 MySQL 的行为
3. 理论上不再会看到这个报错
4、 [FAQ] Txn(Mvcc(Other(“stale request”)))
悲观锁引入的一个错误，3.0.6 以后几乎不会出现了。
5、 [FAQ] Deadlock found when trying to get lock;
如果出现非常频繁，需要调整业务代码来降低死锁发生概率。
6、 [FAQ] DDL job error count exceed the limit, cancelling it now
是否有报错：[tikv:9005]Region is unavailable ，如果有参考官网处理办法：Region is unavailable
7、[FAQ] the schema version is much older than the latest version
v3.0.5 之前版本可以让用户减少同时执行大量 DDL 语句，v3.0.5 及之后版本可以通过 tidb_max_delta_schema_count 变量将其调大。
8、 [FAQ] Information schema is changed
参考 原因分析 里面的官网链接，主要是 3 种情况。如果是情况 1，那么只能重新执行此 DML；如果是情况 2，那么调整 tidb_max_delta_schema_count 值；如果是情况 3，那么需要确保 TiDB 与 TiKV 或者 PD 的网络正常。
9、 [FAQ] Information schema is out of date
1. 确认一下 TiDB 与 TiKV 或者 PD 之前的网络是否正常；
2. 如果网络没问题，确认一下接收到此 DML 的 TiDB 是否被 kill
10、 [FAQ]batchRecvLoop error when receive
1、确认是否有 TiKV 卡住或挂掉
2、确认 TiDB 与 TiKV 之间的网络有问题
11、 [FAQ] region epoch is ahead of tikv
无
12、 [FAQ] GC life time is shorter than transaction duration
优化 SQL 语句临时调整 GC 时间
update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';
其中 30m 代表仅清理 30 分钟前的数据，这可能会额外占用一定的存储空间
13、 [FAQ] invalidate current region, because others failed on same store
如果长期大量报错，应该排查发送请求失败的日志和确认 store 工作状态和网络联通情况，如果 store 和 网络都正常，需进一步排查 TiDB 是否有程序实现问题
14、 [FAQ] conn0 txn takes too much time
1、调大 gc，然后再调大max-txn-time-use
2、优化 SQL 语句
15、 [FAQ] serverBusy backoffer.maxSleep 40000ms is exceeded,
需进一步排查 TiKV 确定一直 busy 的原因，参考 [tikv:9003] TiKV server is busy 报错排查思路。
16、 [FAQ] other error: request outdated
若业务侧的确需要执行超大请求，可调长请求执行时间限制（TiKV 修改参数 end-point-request-max-handle-duration
17、 [FAQ] transport is closing
查看是否有 PD leader 切换或者排查网络以及 PD 节点状态
排查客户端具体报错信息
第一种情况下不需要处理，参考 ：https://asktug.com/t/topic/36843
第二种情况需要排查报错的语句中是否有类型转换的字段或者字段值太长问题
20、[FAQ] region is unavailable
排查 TiKV Region 工作情况，参考文档 region is unavailable
21、 [FAQ] get timestamp too slow
1、查看 PD 节点的负载，如果确认是 PD 机器卡了，需要检查是不是 PD 机器上有其他服务占用了很多资源
2、查看 TiDB 节点的负载、TiDB 监控面板上的 pd client cmd duration 等来定位是不是 TiDB 节点卡了
3、观察 node_exporter 监控页面上的 tcp retrans 相关信息，确定网络是否有丢包
22、 [FAQ] connection reset by peer
如果 TiDB 日志中很频繁的出现这个信息，可能因为前端有负载均衡在探测后端服务是否存活，属于正常信息，可以改成使用 status 的端口（默认是 10080）
23、 [[FAQ] ]invalid time format]([FAQ] ]invalid time format)
排查上下游 sql_mode 是否一致；检查上游是否有不合法数值。
无
25、 [FAQ] invalid memory address or nil pointer dereference
升级的时候先升级 TiKV 再升级 TiDB
26、 [FAQ] incorrect utf8 value f09f918c() for column a
如果是升级后才出现报错，解决方案参考 升级 FAQ 中的问题3 ：https://pingcap.com/docs-cn/stable/faq/upgrade/
如果是普通导数据情况下：
方案1，修改 table 的字符集为 utf8mb4
方案2， set @@session.tidb_skip_utf8_check=1; 或者 set @@global.tidb_skip_utf8_check=1; 跳过 utf8 检查，如意，跳过检查后，重新倒入数据回 MySQL 会报错，还是建议采用方案1
27、 [FAQ] write: connection reset by peer
修复 PR：https://github.com/pingcap/tidb/pull/15731
28、 [FAQ] Data is corrupted, missing data for NOT NULL column
修复 PR：https://github.com/pingcap/tidb/pull/16006
修复 PR：https://github.com/pingcap/tidb/pull/15512
30、 [FAQ] Specified key was too long; max key length is 767 bytes
TiDB 目前没有做这个约束。 如果对业务没有影响的话，可以将此 create 语句中的 “ROW_FORMAT = Compact” 约束去掉。
31、 [FAQ] command 9 not supported now
不影响使用