TiDB5.4作为年开山之作，包含了许多有用有益的新功能和持续性的性能/稳定性提升。本文着重介绍重要新增功能和特性所带给用户的新体验和价值，按照以下章节来组织：
基础性能优化和提升
面向云环境的功能拓展
产品易用性和运维支持
新增实用性功能涉及到的系统配置开关选项
主要的bug修复和稳定性提升
更多详细内容还可以参照ReleaseNotes和用户手册。
基础性能优化和提升
TiDB5.4在性能提升方面实现了以下的重要改进：查询计划可利用多个列上的索引进行高效条件过滤相关的优化工作，即通过正式支持索引合并查询优化功能，使此类查询的性能获得数量级的提升，并且具有响应时间稳定不占系统资源的突出特点；对于数据量大、读写更新频繁的分析场景，TiFlash存储引擎的性能优化将使CPU占用率在现有基础上显著降低并间接帮助提升并发查询下的总体性能；最后，TiDB5.4在大规模数据同步场景下显著提升了同步工具Lightning的性能使得大规模的数据同步任务更轻松快捷。
TiFlash存储层大幅优化行存到列存转码效率
用户场景与挑战
HTAP平台和应用中，数据更新和大量扫表行为交织在一起，存储系统的效能是影响性能和稳定性的关键因素，重度用户总是期待系统能有更好的性能并承载更多的业务。特别是TiDBHTAP采用了事务处理与分析查询物理分离的架构，同一份数据根据业务的需要，在后台进行自动的行式存储到列式存储的转换以分别响应OLTP和OLAP两种类型的负载。存储层大幅优化了从TiKV“行”存储到TiFlash“列”存储格式的转换效率，在“行-列”转换环节的CPU效率大幅提升，进而使得高负载情况下可以节约出更多的CPU资源用于其他环节的计算任务。
解决方案与效果
TiDB5.4重新梳理了TiFlash中行存到列存转码模块的代码架构，大量简化了冗余的数据结构和判断逻辑，采用CPU缓存和向量化友好的数据结构和算法，从而大幅提高运行效率。另外，新版本还相应地优化了TiFlash的存储引擎DeltaTree的默认配置，综合效果的确认参见下文。
列式存储引擎写入性能验证：在不同并发情况下吞吐性能提高60%～90%
验证环境：
6TiKV（1副本）、1TiFlash（1副本），每个节点40个CPU逻辑core，CH-benCHmark(warehouse)。
CH-benCHmark测试结果：10并发下部分查询（Q1、Q6）性能提高约20%
测试环境：
3TiKV（3副本）、2TiFlash（2副本），每个节点40个CPU逻辑core，CH-benCHmark(warehouse)。
小结
TiDB行存与列存之间的数据转换同步通常被外界认为是一种较大的overhead，但是经过努力，今后TiDB的行列转换在架构保持大体不变的情况下，实际运行时已经不构成明显的性能瓶颈。
TiDB正式支持索引合并查询优化
用户场景与挑战
以往有些查询在逻辑上需要同时扫描多个列，而之前版本的TiDB处理区域扫描的查询中只能选择单独某一列（或多列）上的索引（或一个复合列索引），即便各列上都已经有索引但整体的性能受此影响不能达到理想状态。在TiDB5.4版本中，正式提供了索引合并功能，得以允许优化器在查询处理中同时选择使用多列的索引以减少回表，达到超过一两个数量级的过滤效果。对于此类以往容易形成性能瓶颈的问题在查询时间和性能稳定性上都有较大帮助，例如（参见下文）查询的响应时间可以由毫秒缩短30倍至20毫秒，并提升一个数量级的查询并发度。
解决方案
TiDB在原有三种读数据算子基础上增加了第四种类型的算子IndexMergeReader：
TableReader
IndexReader
IndexLookUpReader
IndexMergeReader
前两种比较好理解，直接读取主表数据或者索引表数据。IndexLookUpReader（回表算子）会先读取索引表，得到row_id，再根据row_id从主表中读取数据。
IndexMergeReader执行流程类似于IndexLookUpReader，区别在于可以利用多个索引进行回表，在如下例的场景可以极大提升查询的性能：
SELECT*FROMt1WHEREcORc;
上述查询中如果c1/c2上都有索引，但是由于过滤条件是OR，无法单独使用c1或c2索引，导致只能进行全表扫。使用索引合并可以解决无法使用索引的问题：索引合并会单独利用c1/c2索引得到row_idx，然后将两个索引拿到的row_id进行UNION操作，以UNION操作的结果从主表中获取实际行。
索引合并优势场景
数据来源为以TPC-HSF1（lineitem表行数为W），使用如下的查询来获取lineitem表中价格为，或者orderkey为且