1、TiDB自身问题
•版本迭代速度快，bug多,需多次升级，影响业务
•大版本内，控制在小版本差异多余5个版本+，才可能进行升级
•大版本稳定后，再进行升级，多数为 x.0.2之后
•老版本宕机对业务影响大
•及时升级，新版本改善很大，当前版本影响很小
•对机器硬件要求高，需要大量资源，例如CPU,内存，磁盘
•当前58使用的机器：磁盘闪存卡(不是限制)，内存256G(不是限制)，CPU32核(对性能有一定影响)
•优化器不稳定，存在走索引错误，导致查询时间长
•表统计信息不正确，DBA会定期analyze 表，修正统计信息
•关注表索引情况，分析慢SQL走索引信息
•与MySQL存在一定差异，部分SQL等不支持
•常用的均支持，存在部分函数不支持，推荐上线前进行SQL语句测试
•外键、触发器等不支持，程序实现
•磁盘使用越多，性能会有一定下降
•默认资源不变情况，磁盘使用越多，性能会有一定下降，推荐及时清理无用数据
•DBA会及时扩容资源
•参数调整、升级需要重启集群
•部分参数调整、升级版本需要重启集群，对业务有影响，但是会提升性能，低峰期操作
•部分扩容会影响性能
•TiDB、PD扩容不影响性能
•TiKV节点扩容需要均衡数据，有一定性能影响，速度可调，会比较慢的均衡
•快速提升集群性能较难
•可以快速提升TiDB节点数量，来应对高的入口流量
•如果底层TiKV性能不满足，扩容后需要等数据均衡完成，才能真正提升集群性能
•大集群备份难做
•小于3T集群，每天全备份；
•超3T以上集群，默认不备份
•超3T集群，会进行部分表级别备份
•当前只支持小于3T的集群的单表恢复到备份时间点
•DDL为串行执行
•表结构变更为串行执行
2、TiDB使用姿势及注意
•单机多实例
•58 TiDB Server、PD Server为独立虚拟机，相互之间影响很小
•为提供资源利用率，TiKV Server单机2-3实例部署，会有一定影响，要注意SQL
•单集群多库
•部分老集群存在单机群多库情况，库之间的慢SQL会相互影响，注意SQL效率
•新申请的库，如果体量小、流量小，可能会复用集群；量大的库会独立部署集群，要评估好库的增长、流量情况
•慢SQL影响大
•相比MySQL，TiDB因表条数巨大，导致慢SQL影响较大，日常要多注意SQL效率
•DBA有kill 超时SQL机制，默认超过90s即kill
•历史数据问题
•历史数据要注意保留时长，不用的历史数据及时清理
•清理数据，推荐按照主键循环分批次删除，单次2k条，sleep0.5s ,夜晚低峰期删除
•批量写入问题
•如果写入量大，可以尝试单次insert 多个value，推荐单次带10-20个value，太多的value性能会变差，导致慢SQL暴涨
•并发数问题
•并发数不是越多越好，推荐满足业务即可，不要过多设置
•连接重试
•TiDB流量调整，集群升级等均会造成连接断开，有重试，影响小
•大表添加索引慢
•大表添加索引效率不高，推荐设计表时注意索引情况
•添加索引会对集群有一定性能影响，可调整速度，但还是存在影响
•不推荐超过50亿以上的表添加索引
•表主键推荐自增整型
•其他类型主键效率不好，且不方便运维
•MySQL迁移TiDB方便
•MySQL迁移TiDB，DBA会支持，做到实时同步，业务只需要改连接串即可
•推荐前期量小的业务，先使用MySQL，后期量大可以再迁移
•TiDB重要业务集群要周知DBA
•TiDB不推荐影响收入的、影响用户体验的业务使用。
•如果有一定影响的，推荐周知DBA，独立部署等
•任务配置注意
•拉取数据要注意限速，并发度不要调整过高，否则网卡打满，集群性能会下降等。
•有分析的业务可以使用列存TiFlash
•TiFlash为列存引擎，分析SQL效率高，需要独立配置，推荐提前周知DBA进行配置
•分析业务特别重的推荐测试对比TiFlash、DorisDB、ClickHouse
•纯分析的业务，分析SQL多的，量大的，推荐测试下3种分析型的数据库： TiFlash、DorisDB、ClickHouse，择优使用
•DDL不影响读写
•改表操作、加索引等不影响读写，为在线添加，会有一定性能影响
•上线前推荐测试好SQL
•如使用函数种类多的，推荐提前使用TiDB测试环境进行SQL功能测试，防止SQL不兼容
•只写不读的推荐使用ES
•纯的日志记录，推荐使用ES
•大的业务上线要提前申请TiDB
•因每套TiDB机器资源比较多，大的业务上线推荐提前1周申请TiDB