TiDB5.1版本发布，打造流畅的企业级数据库体验

自 TiDB 5.0 发布以来，陆续在金融、互联网 & 新经济、物流等行业用户的生产环境得到应用，收获不少用户的积极评价： TiDB 服务 58 金融、安居客等数仓报表的复杂读取与关联查询，在多表关联查询中，相比 4.0 版本性能最高提升达 90%；

经过网易互娱场景实测，与 4.0 相比 TiDB 5.0 整体性能表现更加稳定，没有出现明显的抖动； TiDB 5.0 在汽车之家大数据 join 与聚合场景的应用中，MPP 体现出明显的优势，与 MySQL 相比总体效能提升 20 - 50 倍。

“用户的反馈激励我们不断前行，我们的使命是持续提升开发者和 DBA 的体验，让用户用得省心，用得顺手” PingCAP 联合创始人兼 CTO 黄东旭说，“ TiDB 每一个版本的发布都立足于解决 DBA 的痛点。

真实场景就是最好的架构师，从 5.0 版本开始 TiDB 缩短了发版周期，采用了更灵活、更敏捷的火车发版模型，每一个用户真实场景需求的输入，在两个月周期内就有可能成为下一个版本交付的功能”得益于大量用户真实应用场景的快速反馈，TiDB 5.1 提速发版，进一步打造更流畅的企业级数据库体验。

TiDB 5.1 拥有更加稳定的响应延迟表现，更优的 MPP 性能与稳定性，更便捷的可运维性，开发者和 DBA 可以轻松地基于 TiDB 5.1 构建任意规模的关键业务应用TiDB 5.1 功能亮点和用户价值

支持 ANSI SQL 99 标准的 Common Table Expression，用户可以写出更加简洁、更易维护的 SQL 代码，轻松应对复杂的业务逻辑，提高开发效率 进一步提升 MPP 性能和稳定性，帮助用户更快做出实时决策。

5.1 通过支持 MPP 模式下的分区表以及新增的多个函数表达式和算子优化，实时分析性能提升一个数量级以上；通过增强的内存管理和负载平衡机制，让分析查询变得更快、更稳 在突发的大流量写入、集群扩缩容以及在线数据导入和备份等场景下，5.1 版本优化了数据库的长尾查询延迟的稳定性，应对不同的工作负载，延迟能够降低 20% - 70% 。

尤其对于金融行业延迟敏感类型的关键业务应用，大幅提升了在高压力负载下的查询稳定性 支持列类型变更，与 MySQL 兼容度更高5.1 新增 Stale Read 模式，在读写分离场景中通过打散读热点大幅提升读吞吐能力；引入新的系统表，实现在高并发事务场景中快速定位锁冲突；改进统计信息分析引擎，提升优化器选择索引的精准度，保障业务查询的效率和稳定性。

面向大集群提供更加友好的运维体验，进一步降低 DBA 工作负荷5.1 版本集群扩缩容和数据迁移速度提升 40%，改善了大规模集群运维的可靠性，降低大规模集群整体备份和恢复的耗时，通过优化 CDC 数据链路临时中断后的自动恢复机制，进一步提升数据同步链路的可靠性。

Common Table Expression - 让 SQL 化繁为简在金融交易类场景，由于业务的客观复杂性，有时候会写出长达 2000 行的单条 SQL 语句，其中包含大量的聚合和多层子查询嵌套，维护此类 SQL 堪称开发人员的噩梦。

5.1 版本支持 ANSI SQL 99 标准的 Common Table Expression（CTE）及递归的写法，极大提升开发人员和 DBA 编写复杂业务逻辑 SQL 的效率，增强代码的可维护性

HTAP 实时分析能力再升级进一步提升 MPP 的性能和稳定性5.1 版本进一步增强 TiFlash MPP 计算引擎的综合能力，帮助用户提升业务决策速度： MPP 支持分区表，结合业务逻辑可优化海量数据分析查询所消耗的资源，提升查询速度；

新增多个常用 SQL 函数支持，并优化算子使得查询能够更充分利用 MPP 来加速； 提供便利的强制 MPP 模式开关，用户可自主决定是否开启 MPP 模式； 通过优化集群负荷的分散与平衡机制，消除热点，提升系统“综合”承载能力；

修复引擎内存使用问题，提供更加平稳流畅的使用体验 升高压力负载下查询分析的稳定性在金融类业务场景下，技术人员每天会对数据进行高压力的跑批计算，生成最新的市场和营销分析报告，以辅助商业决策跑批流程对连续性要求极高，无法容忍中间过程出错。

针对该场景，5.1 版本优化了 TiDB 的请求重试机制和 TiKV 的请求处理机制，显著降低了在高负载下由于 TiFlash 同步数据不及时导致的 Region Unavailable 出错概率无缝集成 TiSpark。

TiSpark 5.1 版本实现了对含有聚簇索引表的读写支持，不带来任何额外的性能开销，对用户完全透明，用户可以立刻迁移到新版 TiSpark 来体验与 TiDB 5.1 的无缝集成降低读写延迟抖动在延迟敏感的应用场景下，当线上产生突发写流量、操作 TiDB 扩缩容、后台执行统计任务，以及在线数据导入和备份时，可能造成数据库的 P99 和 P999 百分位的延迟抖动，对长尾查询产生一定影响.

TiDB 5.1 加强了对磁盘读写链路的管理，限制后台任务对磁盘资源的使用，大幅降低上述场景对线上业务的干扰，改善读写链路的效率和稳定性在 AWS EC2 r5b.4xlarge 实例挂载 EBS gp3 盘的环境下，通过 TPC-C 基准测试（10k WH）的实测结果：。

操作集群从 6 台 TiKV 缩到 3 台，P99 响应时间降低 20%，P999 响应时间降低 15%； 执行在线导入 200GB 数据，P99 响应时间降低 71%，P999 响应时间降低 70%。

增强业务开发灵活性支持列类型变更在典型的 TiDB 应用场景中，经常借助 binlog 将多个 MySQL 上游数据汇聚到一个 TiDB 集群原先 TiDB 不支持变更列类型的操作，如果上游 MySQL 修改表的字段类型会导致与 TiDB 数据同步的中断。

5.1 版本新增对修改列类型 DDL 语句的支持，彻底解决上述问题并进一步提升 MySQL 兼容性Stale ReadStale Read 适用于读多写少并且能够容忍读到旧数据的场景例如 Twitter 用户发出一条消息后，系统会产生成千上万甚至上亿次读取，并且新发出的消息在一定时间后被读到是可以容忍的。

该场景给数据库带来相当大的读并发压力，可能会产生读热点，导致节点的负载分布不均，整体吞吐成为瓶颈借助 Stale Read，用户可以指定一个过去的时间点从任意一个数据副本读取数据（不必从 leader 读取），从而显著分散节点的压力负载，使得整体读吞吐能力提升近一倍。

/* 例如：可以通过设置当前事务为查询 5 秒之前的数据状态来开启 Stale Read */ > SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL

5 SECOND;> SELECT * FROM T;Copy快速定位锁冲突(实验特性)业务开发需要很谨慎地处理数据库并发事务，一旦发生锁表会给线上业务带来巨大影响，而 DBA 需要快速定位锁表原因以保证业务能够恢复正常。

TiDB 5.1 中新增 Lock View 系统表视图，可以快速定位到引起锁表的事务和相关 SQL 语句，从而提高锁冲突问题的处理效率下面一个小例子展示如何使用 Lock View 快速定位发生锁表的事务和 SQL 语句。

/* 1. 获取当前发生锁等待的事务相关信息: */ mysql> SELECT B.ID,B.STATE,B.WAITING_START_TIME,B.ALL_SQL_DIGESTS FROM DATA_LOCK_WAITS A,TIDB_TRX B WHERE A.CURRENT_HOLDING_TRX_ID

= B.ID OR A.TRX_ID=B.ID \G; *************************** 1. row *************************** ID: 426015366622478337

STATE: LockWaiting WAITING_START_TIME: 2021-07-01 14:19:15.652134 ALL_SQL_DIGESTS: [c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de

] *************************** 2. row *************************** ID: 426015363607822337 STATE: Normal WAITING_START_TIME: NULL ALL_SQL_DIGESTS:

[3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d]2 rows inset(0.00 sec) /* 2. 根据锁表事务提供的 SQL 指纹，进一步找出事务执行过的历史 SQL */ /* 持有锁事务历史执行 SQL*/ mysql

> SELECT DIGEST_TEXT,DIGEST FROM CLUSTER_STATEMENTS_SUMMARY WHERE DIGEST IN(3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d

)\G; *************************** 1. row *************************** DIGEST_TEXT: update a setid= ? DIGEST: 3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d

1 row inset(0.00 sec) /* 请求锁事务历史执行 SQL*/ mysql> SELECT DIGEST_TEXT,DIGEST FROM CLUSTER_STATEMENTS_SUMMARY WHERE DIGEST IN

(c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de)\G; *************************** 1. row *************************** DIGEST_TEXT: delete from a DIGEST: c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de

1 row inset(0.01 sec)Copy更快更准的统计信息分析随着业务数据持续不断的变更，表的统计信息也会变得陈旧，进而导致优化器执行计划准确度降低，使得查询变慢DBA 通过执行 ANALYZE 操作，对表的统计信息进行重建。

TiDB 5.1 对 ANALYZE 采样算法的性能进行了优化，生成统计信息的平均时间缩减为三分之一，同时新增一项新的统计数据类型，让优化器选择索引更加准确提升大集群运维和数据传输的可靠性超多数量表的备份优化

优化超多数量表的备份，在 50k 张表的量级下，TiDB 集群全量备份时间降低到之前的 30~40%此外， 5.1 版本优化了备份模块的元信息文件组织形式（简称v2），启动 BR 时可以通过指定参数 “--backupmeta-version=2” 来启用 v2，从而减少单次写入量来降低内存消耗，有效避免低规格内存（≤8GB）环境下的异常退出。

提升大规模集群运维可靠性TiDB 集群规模越大对生产集群扩缩容、硬件升级以及节点搬迁等日常运维操作的耗时就越久TiDB 5.1 显著提升了扩缩容时数据迁移的性能，以下是两组测试结果： 100 个节点规模下，完成集群所有数据跨数据中心迁移的耗时降低 20%； 。

增加新节点或对某节点的数据进行迁移，耗时缩短约 40% 优化内存使用内存溢出（Out Of Memory）一直是困扰数据库行业的典型问题，5.1 版本针对 TiDB 的内存使用进行了一系列优化，从而降低 OOM 风险：。

无论数据量大小，窗口函数 row_number 将只占用固定大小内存； 优化分区表的读取，占用更少内存； 为存储层加入可配置的内存限制，当限制触发时，系统将释放部分缓存以降低内存占用； TiFlash 写入的内存占用比上一版本降低 80%。

提升 CDC 同步链路可靠性TiCDC 5.1 在无需人工干预的情况下提供同步链路的可靠性：当发生环境扰动或硬件故障时，TiCDC 可以保证同步持续进行；即使发生同步中断，TiCDC 也会根据实际情况自动进行重试。

最后，特别感谢小米、奇虎 360、知乎、爱奇艺、理想汽车、新浪、虎牙、小电、跨越速运、亿玛科技等公司和社区开发者们在 TiDB 5.1 版本的设计、开发和测试过程中做出的贡献，是你们一如既往的支持，帮助 TiDB 在实际场景中持续提升开发者和 DBA 的使用体验，让 TiDB 变得更加简单易用。

查看 TiDB 5.1 Release Notes，立即下载试用，开启 TiDB 5.1 之旅。ReleaseTiDB

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。