TiDB 5.4 作为 2022 年开山之作，蕴含了许多有用无益的新性能和持续性的性能/稳定性晋升。本文着重介绍重要新增性能和个性所带给用户的新体验和价值，依照以下章节来组织：
根底性能优化和晋升
面向云环境的性能拓展
产品易用性和运维反对
新增实用性性能波及到的系统配置开关选项
次要的 bug 修复和稳定性晋升
更多具体内容还能够参照 Release Notes 和 用户手册 。
根底性能优化和晋升
TiDB 5.4 在性能晋升方面实现了以下的重要改良：查问打算可利用多个列上的索引进行高效条件过滤相干的优化工作，即通过正式反对索引合并查问优化性能，使此类查问的性能取得数量级的晋升，并且具备响应工夫稳固不占系统资源的突出特点；对于数据量大、读写更新频繁的剖析场景， TiFlash 存储引擎的性能优化将使 CPU 占用率在现有根底上显著升高并间接帮忙晋升并发查问下的总体性能；最初，TiDB 5.4 在大规模数据同步场景下显著晋升了同步工具 Lightning 的性能使得大规模的数据同步工作更轻松快捷。
TiFlash 存储层大幅优化行存到列存转码效率
用户场景与挑战
HTAP 平台和利用中，数据更新和大量扫表行为交错在一起，存储系统的效力是影响性能和稳定性的关键因素，重度用户总是期待零碎能有更好的性能并承载更多的业务。特地是 TiDB HTAP 采纳了事务处理与剖析查问物理拆散的架构，同一份数据依据业务的须要，在后盾进行主动的行式存储到列式存储的转换以别离响应 OLTP 和 OLAP 两种类型的负载。存储层大幅优化了从 TiKV “行”存储到 TiFlash “列”存储格局的转换效率，在“行 - 列”转换环节的 CPU 效率大幅晋升，进而使得高负载状况下能够节约出更多的 CPU 资源用于其余环节的计算工作。
解决方案与成果
TiDB 5.4 从新梳理了 TiFlash 中行存到列存转码模块的代码架构，大量简化了冗余的数据结构和判断逻辑，采纳 CPU 缓存和向量化敌对的数据结构和算法，从而大幅提高运行效率。另外，新版本还相应地优化了 TiFlash 的存储引擎 DeltaTree 的默认配置，综合成果的确认参见下文。
列式存储引擎写入性能验证：在不同并发状况下吞吐性能进步 60%～90%
验证环境：
6 TiKV（ 1 正本）、1 TiFlash（ 1 正本），每个节点 40 个 CPU 逻辑 core，CH-benCHmark (1500 warehouse)。
CH-benCHmark 测试后果： 10 并发下局部查问（Q1、Q6）性能进步约 20%
测试环境：
3 TiKV（ 3 正本）、2 TiFlash（ 2 正本），每个节点 40 个 CPU 逻辑 core，CH-benCHmark (1500 warehouse)。
小结
TiDB 行存与列存之间的数据转换同步通常被外界认为是一种较大的 overhead， 然而经过努力，今后 TiDB 的行列转换在架构放弃大体不变的状况下，理论运行时曾经不形成显著的性能瓶颈。
TiDB 正式反对索引合并查问优化
用户场景与挑战
以往有些查问在逻辑上须要同时扫描多个列，而之前版本的 TiDB 解决区域扫描的查问中只能抉择独自某一列（或多列）上的索引（或一个复合列索引），即使各列上都曾经有索引但整体的性能受此影响不能达到现实状态。在 TiDB 5.4 版本中，正式提供了索引合并性能，得以容许优化器在查询处理中同时抉择应用多列的索引以缩小回表，达到超过一两个数量级的过滤成果。对于此类以往容易造成性能瓶颈的问题在查问工夫和性能稳定性上都有较大帮忙，例如（参见下文）查问的响应工夫能够由 600 毫秒缩短 30 倍至 20 毫秒，并晋升一个数量级的查问并发度。
解决方案
TiDB 在原有三种读数据算子根底上减少了第四种类型的算子 IndexMergeReader：
TableReader
IndexReader
IndexLookUpReader
IndexMergeReader
前两种比拟好了解，间接读取主表数据或者索引表数据。IndexLookUpReader（回表算子）会先读取索引表，失去 row_id，再依据 row_id 从主表中读取数据。
IndexMergeReader 执行流程相似于 IndexLookUpReader，区别在于能够利用多个索引进行回表，在如下例的场景能够极大晋升查问的性能：
SELECT * FROM t1 WHERE c1 < 10 OR c2 < 100;
上述查问中如果 c1/c2 上都有索引，然而因为过滤条件是 OR，无奈独自应用 c1 或 c2 索引，导致只能进行全表扫。应用索引合并能够解决无奈应用索引的问题：索引合并会独自利用 c1/c2 索引失去 row_idx ，而后将两个索引拿到的 row_id 进行 UNION 操作，以 UNION 操作的后果从主表中获取理论行。
索引合并劣势场景
数据起源为以 TPC-H SF 1 （lineitem 表行数为 600W），应用如下的查问来获取 lineitem 表中价格为 930，或者 orderkey 为 10000 且 comment 为特定字符串的行：
SELECT l_partkey, l_orderkey
FROM lineitem
WHERE ( l_extendedprice = 930
OR l_orderkey = 10000 AND Substring(Lpad(l_comment, 'b', 100), 50, 1) = 'b' )
AND EXISTS(SELECT 1
FROM part
WHERE l_partkey = p_partkey);
不应用索引合并时，执行工夫为 3.38s+
应用索引合并时，执行工夫为 8.3ms：
索引合并非舒服场景
如果应用过滤性很差的条件，则间接应用全表扫的性能会比应用索引合并更好
SELECT l_partkey, l_orderkey
FROM lineitem
WHERE ( l_extendedprice >= 930
OR l_orderkey >= 10000 )
AND EXISTS(SELECT 1
FROM part
WHERE l_partkey = p_partkey);
上面的查问没有应用索引合并，执行工夫只有 2.34s
应用 hint 强制优化器抉择索引合并，因为须要额定的回表工夫，执行工夫须要 19.79s
无显著收益场景
在以下场景中，应用索引合并不会带来显著的收益 在数据量不大的状况下，因为数据很快能扫描并过滤实现，应用索引合并不会有很大收益 在过滤条件计算比拟快的状况下（例如只是整型的比拟），即便数据量绝对较大（例如百万行级别），绝对于全表扫，索引合并也不会有很大晋升。
如下查问，尽管条件的过滤性很高，然而因为计算比拟轻量级（只是整型的比拟），计算都在 TiKV 实现，所以应用索引合并(26ms) 和不应用索引合并(30ms) 性能差别不大。
SELECT l_partkey, l_orderkey
FROM lineitem
WHERE ( l_extendedprice <= 930
OR l_orderkey = 10000 )
AND EXISTS(SELECT 1
FROM part
WHERE l_partkey = p_partkey);
资源耗费
在索引合并劣势场景的查问中，因为大部分行曾经在 TiKV 过滤掉，所以 CPU/内存资源耗费根本能够疏忽。
未应用索引合并的查问，因为过滤条件无奈下推，导致须要将所有行都传给 TiDB 进行 Selection 操作，内存耗费较大，在 10 个并发查问状况下，TiDB 须要 2G 内存来过滤 600W 行数据。
小结
在过滤条件选择率较高时，能够思考应用索引合并。数据流量较大且过滤条件较好的场景，查问响应工夫可缩短 2 个数量级（本文给出的例子是 400 倍），将秒级响应的查问变为毫秒级。
索引合并可大幅缩小并发查问时的系统资源耗费，特地是过滤条件无奈下推的查问（耗费资源较大）能够达到颠覆性的成果（例如本来耗费 2GB 的查问，应用索引合并之后资源耗费甚至能够忽略不计）。
TiDB Lightning 新增高效的反复数据检测个性
用户场景与挑战
在生产环境中，因为历史起因，用户的各个分片 MySQL 实例的数据可能存在反复，当主键/惟一索引反复时则造成抵触数据。因而在将多个分片 MySQL 合并导入上游 TiDB 时必须进行检测和解决，且可能高达几十 TB 的单表数据量对检测效率也是一项极大的挑战。
解决方案
TiDB Lightning 是用于从 CSV/SQL 文件高速导入大规模数据到新 TiDB 集群的工具。Lightning 的 local backend 模式可将源数据编码为有序键值对，直接插入 TiKV 存储，其导入效率极高，并且反对应用多台主机并行导入一张表，是目前初始化 TiDB 集群数据的罕用形式。
在 local backend 模式下，数据导入并不会通过事务写入的接口，因而无奈在插入时检测抵触数据。在之前的版本， Lightning 仅能通过比照 KV 级别的校验码来实现，但局限性较大，仅能通晓产生了谬误，却无奈定位抵触数据的地位。
新增的反复数据检测个性使得 Lightning 精准检测抵触数据，并且内置了一种抵触数据删除算法以主动聚合。检测到抵触数据后， Lightning 能够将其保留以供使用者筛选后再次插入。
反复数据检测个性默认敞开，能够在应用时依据不同的场景需要设置 record/remove 等不同的解决形式。
具体性能验证数据可参考下表：
小结
应用 Lightning 并行导入个性，开启反复数据检测，能够精准定位数据源中的抵触数据，执行效率在屡次优化后耗时占比约为总时长的 20%。
面向云环境的性能拓展
TiDB 5.4 器重与云环境的生态联合，特地推出了一项能够大幅节约存储老本的 Raft Engine日志存储引擎,可为用户节约 30% 以上的数据传输费用同时还在某些场合下有额定的性能收益；强化了数据备份效率，在反对 Amazon S3、Google Cloud Storage 的根底上，新增了对 Azure 环境的反对，实现了与世界支流云厂商存储服务的对接。
反对应用 Raft Engine 作为 TiKV 的日志存储引擎
用户场景与挑战
云环境上用户最为关怀的问题之一是老本，数据存储量和 IO 申请所产生的开销不可小觑。通常来说，分布式数据库在解决用户写入时须要复制并长久化记录大量的日志，这无疑会减少用户部署服务的老本。另一方面看，因为云环境下的硬件资源有较为明确的限度，当用户负载产生稳定，而预设的硬件配置无奈满足时，服务质量也会受到显著影响。
解决方案
TiDB 5.4 推出一项试验性功能：Raft Engine，一款自研的 开源 日志存储引擎，相较于应用默认的 RocksDB 引擎，它最大的劣势在于节俭了磁盘带宽的使用量。首先，Raft Engine 将 TiDB 集群的“写入日志”压缩后间接寄存在文件队列中，而不进行额定的全量转储。另外，Raft Engine 领有更为高效的垃圾回收机制，利用过期数据的空间局部性进行批量清理，在大部分场景下不额定占用后盾资源。
这些优化可能大幅升高等同负载下 TiDB 集群中存储节点的磁盘带宽使用量。这意味着，等同程度的集群将能服务更顶峰值的业务输出，而等同强度的业务能够缩减局部存储节点数量来取得近似的服务水平。
另外，作为自研引擎，Raft Engine 具备更轻量的执行门路，在一些场景下显著缩小了写入申请的尾提早。
在试验环境中，TPC-C 5000 Warehouse 负载下，应用 Raft Engine 可能缩小集群约 30% 的总写入带宽，并对前台吞吐有肯定晋升。
详情参见 用户手册 。
小结
应用 Raft Engine 存储集群日志，可能无效缩小写入带宽用量，节俭云上部署老本的同时晋升服务稳定性。
反对 Azure Blob Storage 作为备份指标存储
Backup & Restore (BR) 反对 Azure Blob Storage 作为备份的远端指标存储。在 Azure Cloud 环境部署 TiDB 的用户，能够反对应用该性能不便地将集群数据备份到 Azure Blob Storage 服务中，反对 AD 备份 和 密钥拜访 两种复原形式。囿于篇幅，具体信息请移步用户手册中的 Azure Blob Storage 备份反对 与 内部存储 章节。
产品易用性和运维反对
TiDB 5.4 继续晋升产品易用性和运维效率，做出了以下的致力：为晋升优化器生成执行打算的品质，加强了统计信息的收集和治理性能，能够针对不同的表、分区、索引设置不同的采集配置项并且默认保留设置，不便后续收集统计信息时沿用已有配置项；数据备份过程有时会影响失常业务，这是长久以来困扰一些用户的问题。5.4 BR 新增了备份线程主动调节性能，可显著加重备份带来的负面影响；TiDB 运行过程中产生的大量日志数据处理不当会造成对性能和稳定性的影响，5.4 版本提供了新的试验个性可 应用 Raft Engine 保留日志，能够显著缩小写流量和 CPU 使用率，晋升前台吞吐缩小尾提早；此外，TiDB 自 5.4 开始 反对 GBK 字符集 。
统计信息采集配置长久化
详情参见 用户手册 。
优化备份对集群的影响
详情参见 用户手册 。
新增实用性性能波及到的系统配置开关选项
TiDB 5.4 对系统配置参数的优化做出了许多致力，残缺信息可参见 Release notes 和相干用户手册，本文仅举其中一项代表性的改善点。
反对 session 变量设置有界线过期读
TiDB 是基于 Raft 协定的多正本分布式数据库。面对高并发，高吞吐业务场景，能够通过 follower 节点实现读性能扩大，构建读写拆散架构。针对不同的业务场景，follower 能够提供以下两种读模式：
强统一读：通过强统一读，能够确保所有节点读取的数据实时统一，实用于一致性要求严格的业务场景，然而因为 leader 和 follower 的数据同步提早导致强统一读的吞吐较低、提早较高，特地是在跨机房架构下提早问题被进一步放大。
过期读：过期读是指能够通过快照读取过来工夫的过期数据，不保障实时一致性，解决了 leader 节点和 follower 节点的提早问题，晋升吞吐。该读模式实用于数据实时一致性要求较低或者数据更新不频繁的业务场景。
TiDB 目前反对通过显示只读事务或 SQL 语句的形式开启 follower 过期读。两种形式均反对“指定工夫”的准确过期读和“指定工夫边界”的非准确过期读两种模式，具体用法请参考 过期读官网文档 。
从 TiDB 5.4.0 版本开始，TiDB 反对通过 session 变量设置有界线过期读，进一步晋升易用性，具体设置示例如下：
set @@tidb_replica_read=leader_and_follower
set @@tidb_read_staleness="-5"
通过该设置，TiDB 能够通过 session 变量疾速开启过期读，防止了频繁的显示开启只读事务或者在每个 SQL 内指定过期读语法，晋升易用性，不便批量地实现就近选取 leader 或 follower 节点，并读取 5 秒钟内的最新过期数据，满足准实时场景下低提早、高吞吐数据拜访的业务诉求。
次要的 bug 修复和稳定性晋升
自 TiDB 5.1 版本公布以来，进步稳定性一直“捉虫”，是研发和 QA 团队最优先的工作。5.4 版本总计进行了 200 余项的体验优化，其中次要局部在 Release notes 中记录，其余细节能够参考 GitHub 上的 PR 记录。TiDB 研发和 QA 团队始终秉持对用户负责的姿势，使产品日臻完善，期待博得宽广用户的信赖。
PM 寄语
2022 年是宽广 TiDB 用户事业虎虎生风方兴未艾的一年，心愿 TiDB 5.4 能给用户带来更多的舒心，更多的便当，助力各种利用和业务的衰弱高效倒退。敬请关注 TiDB 官网 ， GitHub 以及各种社交媒体账号，谨代表 TiDB 产品经理（PM） 团队、研发工程与品质团队一道，期待与宽广用户一起创始更美妙的一年。如果您对 TiDB 的产品有任何倡议，欢送来到 internals.tidb.io 与咱们交换。
查看 TiDB 5.4.0 Release Notes ，立刻 下载试用 ，开启 TiDB 5.4.0 之旅。