关于数据库:TiDB-50-RC-Release-Notes

TiDB 5.0.0-rc 版本是 5.0 版本的前序版本。在 5.0 版本中，咱们专一于帮忙企业基于 TiDB 数据库疾速构建应用程序，使企业在构建过程中无需放心数据库的性能、性能抖动、平安、高可用、容灾、SQL 语句的性能问题排查等问题。

在 TiDB 5.0 版本中，你能够取得以下要害个性：

• 开启聚簇索引性能，晋升数据库的性能。例如：TPC-C tpmC 测试下的性能晋升了 39%。
• 开启异步提交事务性能，升高写入数据的提早。例如：Sysbench oltp-insert 测试中提早升高了 37.3%。
• 通过晋升优化器的稳定性及限度零碎工作对 I/O、网络、CPU、内存等资源的占用，升高零碎的抖动。例如：长期测试 72 小时，掂量 Sysbench TPS 抖动标准差的值从 11.09% 升高到 3.36%。
• 引入 Raft Joint Consensus 算法，确保 Region 成员变更时零碎的可用性。
• 优化 EXPLAIN 性能、引入不可见索引等性能帮忙晋升 DBA 调试及 SQL 语句的效率。
• 通过备份文件到 AWS S3、Google Cloud GCS 或者从 AWS S3、Google Cloud GCS 复原到 TiDB，确保企业数据的可靠性。
• 晋升从 AWS S3 或者 TiDB/MySQL 导入导出数据的性能，帮忙企业在云上疾速构建利用。例如：导入 1TiB TPC-C 数据性能晋升了 40%，由 254 GiB/h 晋升到 366 GiB/h。

SQL

反对聚簇索引（试验个性）

开启聚簇索引性能后，TiDB 性能在以下条件下会有较大幅度的晋升, 例如：TPC-C tpmC 的性能晋升了 39%。聚簇索引次要在以下条件时会有性能晋升：

• 插入数据时会缩小一次从网络写入索引数据。
• 等值条件查问仅波及主键时会缩小一次从网络读取数据。
• 范畴条件查问仅波及主键时会缩小屡次从网络读取数据。

  - 等值或范畴条件查问波及主键的前缀时会缩小屡次从网络读取数据。

聚簇索引定义了数据在表中的物理存储程序，表的数据只能依照聚簇索引的定义进行排序，每个表只能有一个聚簇索引。

用户可通过批改 tidb_enable_clustered_index 变量的形式开启聚簇索引性能。开启后仅在创立新表时失效，实用于主键是多个列或者单个列的非整数类型。如果主键是单列整数类型或者表没有主键，零碎会依照原有的形式进行数据排序，不受聚簇索引的影响。

例如，可通过 select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}' 语名可查问 tbl_name 是否有聚簇索引。

• 用户文档
• 相干 issue：#4841

反对不可见索引

DBA 调试和抉择绝对最优的索引时，能够通过 SQL 语句将某个索引设置成 Visible 或者 Invisible，防止执行耗费资源较多的操作，例如：DROP INDEX 或 ADD INDEX。

DBA 通过 ALTER INDEX 语句来批改某个索引的可见性。批改后优化器会依据索引的可见性决定是否将此索引退出到索引列表中。

• 用户文档
• 相干 issue：#9246

反对 EXCEPT/INTERSECT 操作符

INTERSECT 操作符是一个汇合操作符，返回两个或者多个查问后果集的交加。肯定水平上能够代替 Inner Join 操作符。

EXCEPT 操作符是一个汇合操作符，将两个查问语句的后果合并在一起，并返回在第一个查问语句中有但在第二个查问句中不存在的后果集。

• 用户文档
• 相干 issue：#18031

事务

晋升乐观事务执行胜利的概率

乐观事务模式下，如果事务所波及到的表存在并发 DDL 操作和 SCHEMA VERSION 变更，零碎会主动将该事务的 SCHEMA VERSION 更新到最新版本，确保事务会提交胜利，防止事务因 DDL 操作而中断。事务中断时客户端会收到 Information schema is changed 的错误信息。

• 用户文档
• 相干 issue：#18005

字符集和排序规定

应用 utf8mb4_unicode_ci 和 utf8_unicode_ci 排序规定和字符集比拟排序时不辨别大小写。

• 用户文档
• 相干 issue：#17596

平安

错误信息和日志信息的脱敏

零碎在输入错误信息和日志信息时，反对对敏感信息进行脱敏解决，防止敏感信息泄露。敏感信息可能是身份证信息、信用卡号等。

• 通过 SQL 语句批改 tidb_redact_log=1 开启 tidb-server 的错误信息和日志信息脱敏性能
• 通过批改 tikv-server 的 security.redact-info-log = true 配置项开启错误信息和日志信息脱敏性能
• 通过批改 pd-server 的 security.redact-info-log = true 配置项开启错误信息和日志信息脱敏性能 #2852 #3011
• 通过批改 tiflash-server 的 security.redact_info_log = true 以及 tiflash-learner 的 security.redact-info-log = true 配置项开启错误信息和日志信息脱敏性能

用户文档

相干 issue：#18566

性能晋升

反对异步提交事务（试验个性）

开启异步提交事务可使提早有较大幅度的升高，例如：Sysbench oltp-insert 测试中开启异步提交事务的提早与不开启时相比升高了 37.3%。

数据库的客户端会同步期待数据库通过两阶段 (2PC) 实现事务的提交。开启 Async Commit 个性后事务两阶段提交在第一阶段提交胜利后就会返回后果给客户端，第二阶段会在后盾异步执行。通过事务两阶段异步提交的形式升高事务提交的提早。

此个性只能显式地批改 tidb_guarantee_external_consistency = ON 变量后能力保障事务的内部一致性。开启后性能有较大幅度的降落。

用户可通过批改 tidb_enable_async_commit = ON 全局变量开启此性能。

• 用户文档
• 相干 issue：#8316

晋升优化器抉择索引的稳定性（试验个性）

优化器若无奈长期稳固地抉择绝对适合的索引，会在很大水平上决定着查问语句的提早是否有抖动。为确保雷同的 SQL 语句不会因为统计信息缺失、不精确等因素导致优化器每次都从多个候选索引选持不同的索引，咱们对统计信息模块进行了欠缺和重构。次要欠缺如下：

• 扩大统计信息性能，收集多列 NDV、多列程序依赖性、多列函数依赖性等信息，帮忙优化器抉择绝对较优的索引。

• 重构统计信息模块，帮忙优化器抉择绝对较优的索引。

  • 从 SKetch 中删除 TopN 值。
  • 重构 TopN 搜寻逻辑。
  • 从直方图中删除 TopN 信息，建设直方图的索引，不便保护 Bucket NDV。

相干 issue：#18065

优化因调度性能不欠缺或者 I/O 限流不欠缺引起的性能抖动问题

TiDB 调度过程中会占用 I/O、Network、CPU、Memory 等资源，若不对调度的工作进行管制，QPS 和延时会因为资源被抢占而呈现性能抖动问题。通过以下几项的优化，长期测试 72 小时，掂量 Sysbench TPS 抖动标准差的值从 11.09% 升高到 3.36%。

• 缩小节点的容量总是在水位线左近稳定引起的调度及 PD 的 store-limit 配置项设置过大引起的调度，引入一套新的调度算分公式并通过 region-score-formula-version = v2 配置项启用新的调度算分公式 #3269
• 通过批改 enable-cross-table-merge = true 开启跨 Region 合并性能，缩小空 Region 的数量 #3129
• TiKV 后盾压缩数据会占用大量 I/O 资源，零碎通过主动调整压缩的速度来均衡后台任务与前端的数据读写对 I/O 资源的争抢，通过 rate-limiter-auto-tuned 配置项开启此性能后，提早抖动比未开启此性能时的抖动大幅缩小 #18011
• TiKV 在进行垃圾数据回收和数据压缩时，分区会占用 CPU、I/O 资源，零碎执行这两个工作过程中存在数据重叠。GC Compaction Filter 个性将这两个工作合二为一在同一个工作中实现，减 I/O 的占用。此个性为实验性个性，通过 gc.enable-compaction-filter = ture 开启 #18009
• TiFlash 压缩或者整顿数据会占用大量 I/O 资源，零碎通过限度压缩或整顿数据占用的 I/O 量缓解资源争抢。此个性为实验性个性，通过 bg_task_io_rate_limit 配置项开启限度压缩或整顿数据 I/O 资源。

相干 issue：#18005

晋升 Real-time BI / Data Warehousing 场景下 TiFlash 的稳定性

• 限度 DeltaIndex 的内存使用量，防止大数据量下内存应用过多导致系统 OOM。
• 限度后盾数据整顿工作应用的 I/O 写流量，升高对前台工作的影响。
• 新减少线程池，排队解决 coprocessor 工作，防止高并发解决 coprocessor 时内存占用过多导致系统 OOM。

其余性能优化

• 晋升 delete * from table where id < ? 语句执行的性能，p99 性能晋升了 4 倍 #18028
• TiFlash 反对同时向本地多块磁盘并发读、写数据，充分利用本地多块磁盘并发的读、写数据的能力，晋升性能

高可用和容灾

晋升 Region 成员变更时的可用性（试验个性）

Region 在实现成员变更时，因为“增加”和“删除”成员操作分成两步，如果此时有故障产生会引起 Region 不可用并且会返回前端业务的错误信息。引入的 Raft Joint Consensus 算法，可晋升 Region 成员变更时的可用性，将成员变更操作中的“增加”和“删除”合并为一个操作，并发送给所有成员。在变更过程中，Region 处于两头的状态，如果任何被批改的成员失败，零碎依然能够应用。用户可通过 pd-ctl config set enable-joint-consensus true 批改成员变量的形式开启此性能。

• 用户文档
• 相干 issue：#18079 #7587 #2860

优化内存治理模块，升高零碎内存溢出的危险

• 缩小缓存统计信息的内存耗费。
• 缩小应用 Dumpling 工具导出数据时的内存耗费。
• 通过将数据加明码的两头后果存储到磁盘，缩小内存耗费。

备份与复原

• BR 反对将数据备份到 AWS S3、Google Cloud GCS（用户文档）
• BR 反对从 AWS S3、Google Cloud GCS 复原数据到 TiDB（用户文档）
• 相干 issue：#89

数据的导入和导出

• TiDB Lightning 反对从 AWS S3 将 Aurora Snapshot 数据导入 TiDB（相干 issue：#266）
• 应用 TiDB Lightning 在 DBaaS T1.standard 中导入 1TiB TPCC 数据，性能晋升了 40%，由 254 GiB/h 晋升到 366 GiB/h
• Dumpling 反对将 TiDB/MySQL 数据导出到 AWS S3（试验个性）（相干 issue：#8，用户文档）

问题诊断

优化 EXPLAIN 性能，收集更多的信息，不便 DBA 排查性能问题

DBA 在排查 SQL 语句性能问题时，须要比拟具体的信息来判断引起性能问题的起因。之前版本中 EXPLAIN 收集的信息不够欠缺，DBA 只能通过日志信息、监控信息或者盲猜的形式来判断问题的起因，效率比拟低。此版本通过以下几项优化事项晋升排查问题效率：

• 反对对所有 DML 语句应用 EXPLAIN ANALYZE 语句以查看理论的执行打算及各个算子的执行详情 #18056
• 反对对正在执行的 SQL 语句应用 EXPLAIN FOR CONNECTION 语句以查看实时执行状态，如各个算子的执行工夫、已解决的数据行数等 #18233
• EXPLAIN ANALYZE 语句显示的算子执行详情中新增算子发送的 RPC 申请数、解决锁抵触耗时、网络提早、RocksDB 已删除数据的扫描量、RocksDB 缓存命中状况等 #18663
• 慢查问日志中自动记录 SQL 语句执行时的具体执行状态，输入的信息与 EXPLAIN ANALYZE 语句输入信息保持一致，例如各个算子耗费的工夫、解决数据行数、发送的 RPC 申请数等 #15009

用户文档

部署及运维

• TiUP 反对将 TiDB Ansible 的配置信息导入到 TiUP。以前导入 Ansible 集群的时候 TiUP 会将用户的配置放在 ansible-imported-configs 目录上面。用户后续批改配置执行 tiup cluster edit 时，配置编辑界面中不显示导入的配置，会给用户造成困扰。当初导入 TiDB Ansible 配置信息的时候 TiUP 不仅会放一份到 ansible-imported-configs 目录上面，还会导入到 tiup cluster edit 的配置编辑界面，这样用户当前编辑集群配置时就可能看到导入的配置了。

• 加强 TiUP mirror 命令的性能，反对将多个镜像合并成一个，反对在本地镜像公布组件，反对增加组件所有者到本地镜像 #814

  • 金融行业或者大型企业生产环境的变更是一项十分庄重的事件，若每个版本都采纳光盘装置一次，用户应用起来不是很不便。TiUP 晋升 merge 命令将多个安装包合并成一个，不便 DBA 装置部署。
  • 在 v4.0 中，用户公布自建的镜像时须要启动 tiup-server，应用起来不是很不便。在 v5.0 中，执行 tiup mirror set 将以后镜像设置老本地的镜像就能够不便公布自建镜像。