一、应用场景介绍
伴随业务系统快速增长，如今TiDB集群以12节点的数量，支撑了每日约增量2.43亿的海量数据存储，本文也将重点从运维的角度，分享TiDB在北科的一系列应用实践和遭遇的挑战。
二、为什么选择TiDB
2.1 TiDB特点
具有如下的特性：
高度兼容 MySQL，大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB，即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。
水平弹性扩展，通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
分布式事务，TiDB 100% 支持标准的 ACID 事务。
真正金融级高可用，相比于传统主从（M-S）复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。
在TiDB里，完全不用在担心主库的容量问题；
在TiDB里，原生支持OnlineDDL，不用再使用第三方工具引发的其他问题；
在TiDB里，加字段、改字段的操作，秒级完成，不需要在rebuildtable；
在TiDB里，不用再担心主从延迟，引发的一些列不一致相关问题；
在TiDB里，提供了非常详细的监控指标，以及其他生态自动化工具
……
2.3 性能基准测试
硬件配置
| 服务类型 | 主题类型 | 实例数 |
| PD | BMI5(96核/ 384GB/7T NvmeSSD) | 3 |
| TiKV | BMI5(96核/ 384GB/7T NvmeSSD) | 6 |
| TiDB | BMI5(96核/ 384GB/7T NvmeSSD) | 6 |
| Sysbench | BMI5(96核/ 384GB/7T NvmeSSD) | 1 |
| 服务类型 | 软件版本 |
| PD | 3.0.18 |
| TiKV | 3.0.18 |
| TiDB | 3.0.18 |
| Sysbench | 3.0.18 |
写入测试
| 线程数 | QPS | 95%latency (ms) |
| 16 | 7705 | 2.81 |
| 32 | 13338 | 3.82 |
| 64 | 21641 | 5.18 |
| 128 | 33155 | 7.84 |
| 256 | 44574 | 12.08 |
| 512 | 58604 | 17.32 |
| 768 | 67901 | 22.28 |
| 1024 | 75028 | 26.68 |
| 1536 | 86010 | 34.33 |
| 2048 | 92380 | 44.98 |
| 2500 | 96671 | 54.8 |
OLTP读写测试
| 线程数 | QPS | 95%latency (ms) |
| 16 | 18000 | 22 |
| 32 | 35600 | 23.1 |
| 64 | 60648 | 26.68 |
| 128 | 92318 | 33.12 |
| 256 | 113686 | 55.82 |
| 512 | 138616 | 94.1 |
| 768 | 164364 | 134.9 |
| 1024 | 190981 | 167.44 |
| 1536 | 223237 | 204.11 |
| 2048 | 262098 | 231.53 |
| 2500 | 276107 | 272.27 |
只读测试
| 线程数 | QPS | 95%latency (ms) |
| 16 | 24235.51 | 15.27 |
| 32 | 45483.64 | 16.71 |
| 64 | 80193.6 | 17.95 |
| 128 | 123851.61 | 20.37 |
| 256 | 144999.89 | 34.3 |
| 512 | 174424.94 | 58.92 |
| 768 | 183365.72 | 86 |
| 1024 | 200460.98 | 108.68 |
| 1536 | 236120.82 | 153.02 |
| 2048 | 264444.73 | 204.11 |
| 2500 | 285103.48 | 253.35 |
三、在TiDB上遭遇的问题及解决
3.1 TiDB集群整体平均耗时较高，并且Raftstore线程CPU跑满（200%）
稳定性方面，显著提升了大规模集群的稳定性，集群支持 150+ 存储节点，300+TB 存储容量长期稳定运行。
易用性方面有显著的提升，降低用户运维成本，例如：标准化慢查询日志，制定日志文件输出规范，新增 EXPLAIN ANALYZE，SQL Trace 功能方便排查问题等。
性能方面，与 2.1 相比，TPC-C 性能提升约4.5 倍，Sysbench 性能提升约 1.5 倍。因支持 View，TPC-H 50G Q15 可正常运行。
新功能方面增加了窗口函数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）、SQL Plan Management 等特性。
3.2 执行计划异常导致TiDB集群负载高，伴随平均响应耗时升高
自动更新
stats-lease，
stats-lease的默认值是 3s，如果将其指定为 0，那么将不会自动更新。
和统计信息自动更新相关的三个系统变量如下：
系统变量名 | 默认值 | 功能 |
| 0.5 | 自动更新阈值 |
|
| 一天中能够进行自动更新的开始时间 |
|
| 一天中能够进行自动更新的结束时间 |
tbl的修改行数与总行数的比值大于
tidb_auto_analyze_ratio，并且当前时间在
tidb_auto_analyze_start_time和
tidb_auto_analyze_end_time之间时，TiDB 会在后台执行
ANALYZE TABLE tbl语句自动更新这个表的统计信息。
表的健康度信息
优化收益
同时调整tidb_build_stats_concurrency（ANALYZE并发度）降低在 ANALYZE
过程中对集群产生的压力。优化后至今未出现该类现象。
3.3 读写冲突导致的TiDB集群响应耗时升高
相关细节本节不再赘述，详情可阅读Percolator和TiDB事务算法。
（https://pingcap.com/blog-cn/percolator-and-txn）
我们知道 txnLock
代表写写锁，txnLockFast
代表读写冲突。结合监控锁信息、分析TiDB日志，定位到冲突大多来自oms_waybill_tidb
、fvp_scan_gun
表的写入和更新操作。
2.尝试悲观事务锁模型
3.同订单记录操作串行化
四、生态
4.1 DbKiller
4.2 DbCleaner
4.3 Data Migration
（替代了早期的Syncer，满足大部分数据全量、增量同步需求）
5.1 热点问题
图 5 TiKV存储过程
热点规避方式：主键变更，Region预创建
_tidb_rowid列作为行 ID
_tidb_rowid带来的写入热点问题，可以在建表时，使用
SHARD_ROW_ID_BITS和
PRE_SPLIT_REGIONS这两个建表选项
SHARD_ROW_ID_BITS用于将
_tidb_rowid列生成的行 ID 随机打散。
PRE_SPLIT_REGIONS用于在建完表后预先进行 Split region
优化方式：
对于历史数据，直接使用删除分区的方式物理删除，提高删除效率，规避对集群的性能影响。
5.3 数据备份
5.4 集群状态定位难
TiDB虽提供了大量的Dashboard指标可以展示，但在排查各类问题时，还需要很多精力进行分析和定位。在TiDBv4.0版本，引入了TiDB DashBoard组件。通过 TiDB DashBoard 以及 TiDB 的集群的诊断报告，我们可以快速拿到集群的基本信息、负载信息、组件信息、配置信息以及错误信息，这些信息其实已经非常的丰富了，对于我们来讲是非常有效的，可以稳准狠的找到我们的集群的异常
