什么是TiDB 产品优势 产品优势 ⾼度兼容 MySQL 动态扩展 分布式事务 HTAP 真正⾦融级⾼可⽤ 适⽤场景 适⽤场景 对数据⼀致性及⾼可靠、系统⾼可⽤、可扩展性、容灾要求较⾼的⾦融⾏业属性的场景 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 OLTP 场景 Real-time HTAP 场景 数据汇聚、⼆次加⼯处理的场景 真正⾦融级⾼可⽤ UCloud 云上 云上 TiDB 架构⽰意图 架构⽰意图 Multi-Raft 协议 的⽅式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可⾃动进⾏切换，确保系统的 RTO <= 30s 及 RPO = 0。 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 OLTP 场景 场景 随着业务的⾼速发展，数据呈现爆炸性的增⻓，传统的单机数据库⽆法满⾜因数据爆炸性的增⻓对数据库的容量要 命令修改副本数则会重新计算同步进度。 PROGRESS 字段代表同步进度，在 0.0~1.0 之间，1 代表⾄少 1 个副本已经完成同步。 步骤三 步骤三 使⽤ 使⽤TiFlash 同步完成后，TiDB 优化器会⾃动根据代价估算选择是否使⽤ TiFlash 副本。具体有没有选择 TiFlash 副本，可以通过 desc 或 explain analyze 语句查看，例如： desc select count(*) from

采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 24 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 议使用 5.2.x 的最新版本。 在 5.2 版本中，你可以获得以下关键特性： • 支持基于部分函数创建表达式索引 (Expression index)，极大提升查询的性能。 • 提升优化器的估算准确度 (Cardinality Estimation)，有助于选中最优的执行计划。 • 锁视图 (Lock View) 成为 GA 特性，提供更直观方便的方式观察事务加锁情况以及排查死锁问题。 创建生成列或者 表达式索引时引 用自增列，默认 值为OFF。 tidb_opt_ �→ enable_ �→ correlation �→ _ �→ adjustment 新增 控制优化器是否 开启交叉估算， 默认值为ON。 tidb_opt_ �→ limit_push �→ _down_ �→ threshold 新增 设置将 Limit 和 TopN 算子下推 到 TiKV 的阈值， 默认值为100。

采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 23 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 表示所连接的 TiDB 服务器是否 启用了安全增强 模式（SEM），在 不重新启动 TiDB 服务器的情况下 不能改变该变 量。 tidb_enforce_ �→ mpp 新增 用于忽略优化器 代价估算，强制 使用 MPP 模式。 BOOL 类型，默认 值为 false。 tidb_ �→ partition_ �→ prune_mode 新增 用于设置是否开 启分区表动态裁 剪模式（实验特 TCP_NODELAY。 默认值为 true， 代表开启。 TiDB 配置文件 performance. �→ enforce- �→ mpp 新增 用于在实例级 别控制 TiDB 是 否忽略优化器 代价估算，强 制使用 MPP 模 式，默认值为 false。该配置 项可以控制系 统变量tidb_ �→ enforce_ �→ mpp 的初始 值。 TiDB 配置文件 pessimistic- �→

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 语句需要执行的子任务。详见算子简介。 • estRows 为显示 TiDB 预计会处理的行数。该预估数可能基于字典信息（例如访问方法基于主键或唯一 键），或基于 CMSketch 或直方图等统计信息估算而来。 • task 显示算子在执行语句时的所在位置。详见Task 简介。 • access-object 显示被访问的表、分区和索引。显示的索引为部分索引。以上示例中 TiDB 使用了 a 列的

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 保存时间，以避免增量同步时缺必要 binlog 导致重做。 说明：目前无法精确计算 Dumpling 从 MySQL 导出的数据大小，但你可以用下面 SQL 语句统计信息表的 data_length 字段估算数据量： /* 统计所有 schema 大小，单位 MiB，注意修改 ${schema_name} */ SELECT table_schema,SUM(data_length)/1024/1024

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 要查询的行数减少，往往查询速度也会非常快，而且所消耗的资源一般相对 TiFlash 而言会更少。 4.7.9.3.2 指定查询引擎 尽管 TiDB 会使用基于成本的优化器（CBO）自动地根据代价估算选择是否使用 TiFlash 副本。但是在实际使用 当中，如果你非常确定查询的类型，推荐你使用Optimizer Hints 明确的指定查询所使用的执行引擎，避免因为 优化器的优化结果不同，导致应用程序性能出现波动。

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 优化器引入更精准的代价模型 Cost Model Version 2 (GA) #35240 @qw4990 TiDB v6.2.0 引入了代价模型Cost Model Version 2 作为实验特性，通过更准确的代价估算方式，有利于最优 执行计划的选择。尤其在部署了 TiFlash 的情况下，Cost Model Version 2 自动选择合理的存储引擎，避免过 35 多的人工介入。经过一段时间真实场景的测试，这个模型在 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 760 8.5.4 估算 SQL 所消耗的 RU· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · (GA) 支持基于资源组的资源管控，为同一集群中的不同工作负载分配并隔离资源。该功能显著提升了多应用集群 的稳定性，并为多租户奠定了基础。在 v7.1.0 中，资源管控引入了根据实际负载或硬件部署估算集群容量的 能力。 TiFlash 支持0 码力 | 4369 页 | 98.92 MB | 1 年前

3

数据类型的检索性能。在 v8.0.0 中，优化器增强了对多值 索引的支持能力，使其在复杂场景下能够正确识别和利用多值索引来优化查询。 36 – 优化器能够收集多值索引的统计信息，并利用这些信息来估算查询。当一条 SQL 可能选择到数个 多值索引时，优化器可以识别开销更小的索引。 – 在查询条件中使用 OR 连接多个 member of 条件时，优化器能够为每个 DNF Item（member �→ _ratio 新增 当一个 索引满 足 SQL 语句中 的 ORDER �→ BY 和 LIMIT 子句， 但有部 分过滤 条件未 被该索 引覆盖 时，该 系统变 量用于 控制该 索引的 估算行 数。默 认值为 -1，表 示禁用 此系统 变量。 47 变量名 修改类型 描述 tidb_opt_ �→ use_ �→ invisible �→ _ �→ indexes �→ 新增 PREPARE 语 句 无法 命 中 执行 计 划 缓 存时， 支 持 通过 执 行 SHOW WARNINGS 查看 原 因 #50407 @hawkingrei – 提升当多次更新同一行的数据时查询估算信息的准确性 #47523 @terry1purcell – Index Merge 支持在 AND 谓词中内嵌多值索引和 OR 操作符 #51778 @time-and-fate – 当设置 force-init-stats

5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： USE test; EXPLAIN ANALYZE 要查询的行数减少，往往查询速度也会非常快，而且所消耗的资源一般相对 TiFlash 而言会更少。 4.7.9.3.2 指定查询引擎 尽管 TiDB 会使用基于成本的优化器（CBO）自动地根据代价估算选择是否使用 TiFlash 副本。但是在实际使用 当中，如果你非常确定查询的类型，推荐你使用Optimizer Hints 明确的指定查询所使用的执行引擎，避免因为 优化器的优化结果不同，导致应用程序性能出现波动。 目前有以下两种有效的空间预估方法： • 假设数据总大小为 A，索引总大小为 B，副本数为 3，压缩率为 α（一般在 2.5 左右），则总的占用空间 为：(A+B)*3/α。该方法主要用于不进行任何数据导入时的估算，以此规划集群拓扑。 554 • 预先导入 10% 的数据，实际占用空间再乘以 10，即可认为是该批数据最终的占用空间。该方法更加准 确，尤其是对于导入大量数据时比较有效。 注意要预留 20%