TiDB 查询优化及调优系列（五）调优案例实践

于 2022-05-30 12:03:23 发布
阅读量568 收藏 3
点赞数
文章标签： mysql 数据库 sql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/TiDB_PingCAP/article/details/125044164
版权

本篇文章为 TiDB 查询优化及调优系列的最终篇，主要汇集了一些用户常见的 SQL 优化案例，从背景、分析、影响、建议、实操几个角度进行解析。关于 SQL 调优原理的介绍见前面章节。

相关阅读：

TiDB 查询优化及调优系列（一）TiDB 优化器简介

TiDB 查询优化及调优系列（二）TiDB 查询计划简介

TiDB 查询优化及调优系列（三）慢查询诊断监控及排查

TiDB 查询优化及调优系列（四）查询执行计划的调整及优化原理

注：以下语句及结果基本为当时实际环境所记录的情况，因为版本更新原因，可能和现有格式略有差别，如 count 等价于现在的 estRows.

案例1: Delete 涉及数据量过大导致 OOM

MySQL [db_stat]> explain delete from t_stat where imp_date<='20200202';
+---------------------+--------------+------+------------------------------------------------------+
| id                  | count        | task | operator info                                        |
+---------------------+--------------+------+------------------------------------------------------+
| TableReader_6       | 220895815.00 | root | data:Selection_5                                     |
| └─Selection_5       | 220895815.00 | cop  | le(db_stat.t_stat.imp_date, "20200202")              |
|   └─TableScan_4     | 220895815.00 | cop  | table:t_stat, range:[-inf,+inf], keep order:false    |
+---------------------+--------------+------+------------------------------------------------------+
3 rows in set (0.00 sec)
MySQL [db_stat]> select count(*)  from t_stat where imp_date<='20200202';
+-----------+
| count(*)  |
+-----------+
| 184340473 |
+-----------+
1 row in set (17.88 sec)

背景

大批量清理数据时系统资源消耗高，在 TiDB 节点内存不足时可能导致 OOM

分析

imp_date字段上虽然有索引，但是扫描的时间范围过大，无论优化器选择 IndexScan 还是 Table Scan，TiDB 都要向 TiKV Coprocessor 请求读取大量的数据

影响

  • TiKV 节点 Coprocessor CPU 使用率快速上涨
  • 执行 Delete 操作的 TiDB 节点内存占用快速上涨，因为要将大批量数据加载到 TiDB 内存

建议

  • 删除数据时，缩小数据筛选范围，或者加上 limit N 每次删除一批数据
  • 建议使用 Range 分区表，按照分区快速删除

案例2 执行计划不稳定导致查询延迟增加

MySQL [db_stat]> explain SELECT * FROM `tbl_article_check_result` `t` WHERE (articleid = '20190925A0PYT800') ORDER BY checkTime desc LIMIT 100 ;
+--------------------------+----------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id                       | count    | task | operator info                                                                                                                                                                                                                                                                                                                                                                 |
+--------------------------+----------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Projection_7             | 100.00   | root | db_stat.t.type, db_stat.t.articleid, db_stat.t.docid, db_stat.t.version, db_stat.t.checkid, db_stat.t.checkstatus, db_stat.t.seclevel, db_stat.t.t1checkstatus, db_stat.t.t2checkstatus, db_stat.t.mdaichannel, db_stat.t.mdaisubchannel, db_stat.t.checkuser, db_stat.t.checktime, db_stat.t.addtime, db_stat.t.havegot, db_stat.t.checkcode                                 |
| └─Limit_12               | 100.00   | root | offset:0, count:100                                                                                                                                                                                                                                                                                                                                                           |
|   └─IndexLookUp_34       | 100.00   | root |                                                                                                                                                                                                                                                                                                                                                                               |
|     ├─IndexScan_31       | 30755.49 | cop  | table:t, index:checkTime, range:[NULL,+inf], keep order:true, desc                                                                                                                                                                                                                                                                                                            |
|     └─Selection_33       | 100.00   | cop  | eq(db_dayu_1.t.articleid, "20190925A0PYT800")                                                                                                                                                                                                                                                                                                                                 |
|       └─TableScan_32     | 30755.49 | cop  | table:tbl_article_check_result, keep order:false                                                                                                                                                                                                                                                                                                                              |
+--------------------------+----------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
6 rows in set (0.00 sec)

背景

articleid和 checkTime字段上分别建有单列索引，正常情况下走 articleid上的索引比较快，偶尔执行计划不稳定时走 checkTime上的索引，导致查询延迟达到分钟级别

分析

LIMIT 100限定了获取 100 条记录，如果 checkTime和 articleid列之间的相关度不高，在独立性假设失效时，优化器估算走 checkTime上的索引并满足 articleid条件时扫描的行数，可能比走 articleid上的索引扫描的行数更少

影响

业务响应延迟不稳定，监控 Duration 偶尔出现抖动

建议

  • 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度
  • 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗
    • set global tidb_auto_analyze_ratio=0.2;
    • set global tidb_auto_analyze_start_time='00:00 +0800';
    • set global tidb_auto_analyze_end_time='06:00 +0800';
  • 业务修改 SQL ，使用 force index 固定使用 articleid 列上的索引
  • 业务可以不用修改 SQL，使用 SPM （见上述章节）的 create binding 创建 force index 的绑定 SQL，可以避免执行计划不稳定导致的性能下降

案例3 查询字段与值的数据类型不匹配

MySQL [db_stat]> explain select * from t_like_list where person_id=1535538061143263;
+---------------------+------------+------+-----------------------------------------------------------------------------------+
| id                  | count      | task | operator info                                                                     |
+---------------------+------------+------+-----------------------------------------------------------------------------------+
| Selection_5         | 1430690.40 | root | eq(cast(db_stat.t_like_list.person_id), 1.535538061143263e+15)                    |
| └─TableReader_7     | 1788363.00 | root | data:TableScan_6                                                                  |
|   └─TableScan_6     | 1788363.00 | cop  | table:t_like_list, range:[-inf,+inf], keep order:false                            |
+---------------------+------------+------+-----------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

背景

person_id列上建有索引且选择性较好，但执行计划没有按预期走 IndexScan

分析

person_id是字符串类型，但是存储的值都是数字，业务认为可以直接赋值；而优化器需要在字段上做 cast类型转换，导致无法使用索引

建议

where条件的值加上引号，之后执行计划使用了索引：

MySQL [db_stat]> explain select * from table:t_like_list where person_id='1535538061143263';
+-------------------+-------+------+----------------------------------------------------------------------------------------------------------+
| id                | count | task | operator info                                                                                            |
+-------------------+-------+------+----------------------------------------------------------------------------------------------------------+
| IndexLookUp_10    | 0.00  | root |                                                                                                          |
| ├─IndexScan_8     | 0.00  | cop  | table:t_like_list, index:person_id, range:["1535538061143263","1535538061143263"], keep order:false      |
| └─TableScan_9     | 0.00  | cop  | table:t_like_list, keep order:false                                                                      |
+-------------------+-------+------+----------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

案例4 读热点导致 SQL 延迟增加

背景

某个数据量 600G 左右、读多写少的 TiDB 集群，某段时间发现 TiDB 监控的 Query Summary - Duration 指标显著增加，p99 如下图。

查看 TiDB 监控下的 KV Duration 明显升高，其中 KV Request Duration 999 by store 监控看到多个 TiKV 节点 Duration 均有上涨。

查看 TiKV 监控 Coprocessor Overview：

查看监控 Coprocessor CPU：

发现 Coprocessor CPU 线程池几乎打满。下面开始分析日志，调查 Duration 和 Coprocessor CPU 升高的原因。

慢查询日志分析

使用 pt-query-digest工具分析 TiDB 慢查询日志：

./pt-query-digest tidb_slow_query.log > result

分析慢日志解析出来的 TopSQL 发现 Process keys和 Process time并不是线性相关，Process keys数量多的 SQL 的 Process time处理时间不一定更长，如下面 SQL 的 Process keys为 22.09M，Process time为 51s。

下面 SQL 的 Process keys为 12.68M，但是 Process time高达 142353s。

过滤 Process time较多的 SQL，发现 3 个典型的 slow query，分析具体的执行计划。

SQL1

select a.a_id, a.b_id,uqm.p_id from a join hsq on a.b_id=hsq.id join uqm on a.a_id=uqm.id;

SQL2

select distinct g.abc, g.def, g.ghi, h.abcd, hi.jq   from ggg g left join ggg_host gh on g.id = gh.ggg_id left join host h on gh.a_id = h.id left join a_jq hi on h.id = hi.hid   where h.abcd is not null and h.abcd  <>  '' and hi.jq is not null and hi.jq  <>  '';

SQL3

select tb1.mt, tb2.name from tb2 left join tb1 on tb2.mtId=tb1.id where tb2.type=0 and (tb1.mt is not null and tb1.mt != '') and (tb2.name is not null or tb2.name != '');

分析执行计划未发现异常，查看相关表的统计信息也都没有过期，继续分析 TiDB 和 TiKV 日志。

常规日志分析

查看 TiKV 日志中标记为 [slow-query] 的日志行中的 region 分布情况。

more tikv.log.2019-10-16-06\:28\:13 |grep slow-query |awk -F ']' '{print $1}' | awk  '{print $6}' | sort | uniq -c | sort –n

找到访问频率最大的 3 个 region：

73 29452
140 33324
757 66625

这些 region 的访问次数远远高于其它 region，之后定位这些 region 所属的表名。首先查看 [slow-query] 所在行记录的 table_id 和 start_ts，然后查询 TiDB 日志获取表名，比如 table_id 为 1318，start_ts 为 411837294180565013，使用如下命令过滤，发现是上述慢查询 SQL 涉及的表。

more tidb-2019-10-14T16-40-51.728.log | grep '"/[1318/]"' |grep 411837294180565013

解决

对这些 region 做 split 操作，以 region 66625 为例，命令如下（需要将 x.x.x.x 替换为实际的 pd 地址）。

pd-ctl –u http://x.x.x.x:2379 operator add split-region 66625

操作后查看 PD 日志

[2019/10/16 18:22:56.223 +08:00] [INFO] [operator_controller.go:99] ["operator finish"] [region-id=30796] [operator="\"admin-split-region (kind:admin, region:66625(1668,3), createAt:2019-10-16 18:22:55.888064898 +0800 CST m=+110918.823762963, startAt:2019-10-16 18:22:55.888223469 +0800 CST m=+110918.823921524, currentStep:1, steps:[split region with policy SCAN]) finished\""]

日志显示 region 已经分裂完成，之后查看该 region 相关的 slow-query：

more tikv.log.2019-10-16-06\:28\:13 |grep slow-query  | grep 66625

观察一段时间后确认 66625 不再是热点 region，继续处理其它热点 region。所有热点 region 处理完成后，监控 Query Summary - Duration 显著降低。

Duration 稳定了保持一段时间，18:55 之后仍然有较高的 Duration 出现：

观察压力较重的 tikv，移走热点 region 的 leader：

pd-ctl –u http://x.x.x.x:2379 operator add transfer-leader 1 2 //把 region1 的 leader 调度到 store2

leader 迁走之后，原 TiKV 节点的 Duration 立刻下降，但是迁移到新 TiKV 节点的 Duration 随之上升。

之后多次对热点 region 进行 split 操作，最终 Duration 明显下降并恢复稳定。

案例总结

对于分布式数据库的读热点问题，有时难以通过优化 SQL 的方式解决，需要分析整个 TiDB 集群的监控和日志来定位原因。严重的读热点可能导致部分 TiKV 达到资源瓶颈，这种短板效应限制了整个集群性能的充分发挥，通过分裂 region 的方式可以将热点 region 分散到更多的 TiKV 节点上，让每个 TiKV 的负载尽可能达到均衡，缓解读热点对 SQL 查询性能的影响。更多热点问题的处理思路可以参考 TiDB 查询优化及调优系列（四）查询执行计划的调整及优化原理 。

案例5 SQL 执行计划不准

背景

SQL 执行时间突然变长

分析

  • SQL 语句
select count(*)
from   tods.bus_jijin_trade_record a, tods.bus_jijin_info b 
where   a.fund_code=b.fund_code  and a.type in   ('PURCHASE','APPLY')  
and   a.status='CANCEL_SUCCESS' and a.pay_confirm_status = 1 
and a.cancel_app_no   is not null and a.id >=    177045000  
and a.updated_at   > date_sub(now(), interval 48 hour) ;

执行结果，需要 1 分 3.7s：

mysql> select   count(*)
    -> from tods.bus_jijin_trade_record a,   tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and   a.id >=  177045000  
    -> and a.updated_at >   date_sub(now(), interval 48 hour) ;
+----------+
| count(*) |
+----------+
|      708 |
+----------+
1   row in set (1 min 3.77 sec)
  • 索引信息

  • 查看执行计划
mysql> explain 
    -> select count(*)
    -> from tods.bus_jijin_trade_record a,   tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and   a.id >=  177045000  
    -> and a.updated_at >   date_sub(now(), interval 48 hour) ;
+----------------------------+--------------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id                         | count        | task | operator info                                                                                                                                                     |
+----------------------------+--------------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| StreamAgg_13               | 1.00         | root | funcs:count(1)                                                                                                                                                    |
| └─HashRightJoin_27         | 421.12       | root | inner join, inner:TableReader_18, equal:[eq(a.fund_code, b.fund_code)]                                                                                            |
|   ├─TableReader_18         | 421.12       | root | data:Selection_17                                                                                                                                                 |
|   │ └─Selection_17         | 421.12       | cop  | eq(a.pay_confirm_status, 1), eq(a.status, "CANCEL_SUCCESS"), gt(a.updated_at, 2020-03-03 22:31:08), in(a.type, "PURCHASE", "APPLY"), not(isnull(a.cancel_app_no)) |
|   │   └─TableScan_16       | 145920790.55 | cop  | table:a, range:[177045000,+inf], keep order:false                                                                                                                 |
|   └─TableReader_37         | 6442.00      | root | data:TableScan_36                                                                                                                                                 |
|     └─TableScan_36         | 6442.00      | cop  | table:b, range:[-inf,+inf], keep order:false                                                                                                                      |
+----------------------------+--------------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+

TableScan_16，TableScan_36：表示在 TiKV 端分别对表 a 和 b 的数据进行扫描，其中 TableScan_16 扫描了 1.46 亿的行数；
Selection_17：表示满足表 a 后面 where 条件的数据；
TableReader_37： 由于表 b 没有独立的附加条件，所以直接将这部分数据返回给 TiDB；
TableReader_18：将各个 coprocessor 满足 a 表条件的结果返回给 TiDB；
HashRightJoin_27：将 TableReader_37 和 TableReader_18 上的结果进行 hash join；
StreamAgg_13：进一步统计所有行数，将数据返回给客户端；

可以看到语句中 a 表(bus_jijin_trade_record)的条件 id >= 177045000，和 updated_at > date_sub(now(), interval 48 hour)上，这两个列分别都有索引，但是 TiDB 还是选择了全表扫描。

按照上面两个条件分别查询数据分区情况

mysql> SELECT COUNT(*) FROM tods.bus_jijin_trade_record WHERE id >= 177045000 ;
+-----------+
| COUNT(*)  |
+-----------+
| 145917327 |
+-----------+
1 row in set (16.86   sec)

mysql> SELECT COUNT(*) FROM tods.bus_jijin_trade_record WHERE updated_at > date_sub(now(), interval 48 hour)  ;
+-----------+
|  COUNT(*) |
+-----------+
|    713682 |
+-----------+

可以看到，表 bus_jijin_trade_record 有 1.7 亿的数据量，应该走 updated_at 字段上的索引。 使用强制 hint 进行执行，6.27 秒就执行完成了，速度从之前 63s 到现在的 6.3s，提升了 10 倍。

mysql> select   count(*)
    -> from tods.bus_jijin_trade_record a   use index(idx_bus_jijin_trade_record_upt), tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and   a.id >=  177045000  
    -> and a.updated_at >   date_sub(now(), interval 48 hour) ;
+----------+
| count(*) |
+----------+
|      709 |
+----------+
1 row in set (6.27   sec)

强制 hint 后的执行计划：

mysql> explain 
    -> select count(*)
    -> from tods.bus_jijin_trade_record a   use index(idx_bus_jijin_trade_record_upt), tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and   a.id >=  177045000  
    -> and a.updated_at >   date_sub(now(), interval 48 hour) ;
+------------------------------+--------------+------+----------------------------------------------------------------------------------------------------------------------------+
| id                           | count        | task | operator info                                                                                                              |
+------------------------------+--------------+------+----------------------------------------------------------------------------------------------------------------------------+
| StreamAgg_13                 | 1.00         | root | funcs:count(1)                                                                                                             |
| └─HashRightJoin_24           | 421.12       | root | inner join, inner:IndexLookUp_20, equal:[eq(a.fund_code, b.fund_code)]                                                     |
|   ├─IndexLookUp_20           | 421.12       | root |                                                                                                                            |
|   │ ├─Selection_18           | 146027634.83 | cop  | ge(a.id, 177045000)                                                                                                        |
|   │ │   └─IndexScan_16       | 176388219.00 | cop  | table:a, index:UPDATED_AT, range:(2020-03-03 23:05:30,+inf], keep order:false                                              |
|   │ └─Selection_19           | 421.12       | cop  | eq(a.pay_confirm_status, 1), eq(a.status, "CANCEL_SUCCESS"), in(a.type, "PURCHASE", "APPLY"), not(isnull(a.cancel_app_no)) |
|   │   └─TableScan_17         | 146027634.83 | cop  |   table:bus_jijin_trade_record, keep order:false                                                                           |
|   └─TableReader_31           | 6442.00      | root | data:TableScan_30                                                                                                          |
|     └─TableScan_30           | 6442.00      | cop  | table:b, range:[-inf,+inf], keep order:false                                                                               |
+------------------------------+--------------+------+----------------------------------------------------------------------------------------------------------------------------+

使用 hint 后的执行计划，预估 updated_at 上的索引会扫描 176388219，没有选择索引而选择了全表扫描，可以判定是由于错误的统计信息导致执行计划有问题。

查看表 bus_jijin_trade_record上的统计信息。

mysql> show   stats_meta where table_name like 'bus_jijin_trade_record' and db_name like   'tods';
+---------+------------------------+---------------------+--------------+-----------+
| Db_name | Table_name             | Update_time         | Modify_count | Row_count |
+---------+------------------------+---------------------+--------------+-----------+
| tods    | bus_jijin_trade_record | 2020-03-05 22:04:21 |     10652939 | 176381997 |
+---------+------------------------+---------------------+--------------+-----------+

mysql> show   stats_healthy  where table_name like   'bus_jijin_trade_record' and db_name like 'tods';
+---------+------------------------+---------+
| Db_name | Table_name             | Healthy |
+---------+------------------------+---------+
| tods    | bus_jijin_trade_record |      93 |
+---------+------------------------+---------+

根据统计信息，表 bus_jijin_trade_record有 176381997，修改的行数有 10652939，该表的健康度为：(176381997-10652939)/176381997 *100=93。

解决

重新收集统计信息

mysql> set   tidb_build_stats_concurrency=10;
Query OK, 0 rows   affected (0.00 sec)

#调整收集统计信息的并发度，以便快速对统计信息进行收集 
mysql> analyze   table tods.bus_jijin_trade_record;
Query OK, 0 rows   affected (3 min 48.74 sec)

查看没有使用 hint 语句的执行计划

mysql> explain   select count(*)
  -> from tods.bus_jijin_trade_record a,   tods.bus_jijin_info b 
  -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
  -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
  -> and a.cancel_app_no is not null and   a.id >=  177045000  
  -> and a.updated_at >   date_sub(now(), interval 48 hour) ;;
+------------------------------+-----------+------+----------------------------------------------------------------------------------------------------------------------------+
| id                           | count     | task | operator info                                                                                                              |
+------------------------------+-----------+------+----------------------------------------------------------------------------------------------------------------------------+
| StreamAgg_13                 | 1.00      | root | funcs:count(1)                                                                                                             |
| └─HashRightJoin_27           | 1.99      | root | inner join, inner:IndexLookUp_23, equal:[eq(a.fund_code, b.fund_code)]                                                     |
|   ├─IndexLookUp_23           | 1.99      | root |                                                                                                                            |
|   │ ├─Selection_21           | 626859.65 | cop  | ge(a.id, 177045000)                                                                                                        |
|   │ │   └─IndexScan_19       | 757743.08 | cop  | table:a, index:UPDATED_AT, range:(2020-03-03 23:28:14,+inf], keep order:false                                              |
|   │ └─Selection_22           | 1.99      | cop  | eq(a.pay_confirm_status, 1), eq(a.status, "CANCEL_SUCCESS"), in(a.type, "PURCHASE", "APPLY"), not(isnull(a.cancel_app_no)) |
|   │   └─TableScan_20         | 626859.65 | cop  | table:bus_jijin_trade_record, keep order:false                                                                             |
|   └─TableReader_37           | 6442.00   | root | data:TableScan_36                                                                                                          |
|     └─TableScan_36           | 6442.00   | cop  | table:b, range:[-inf,+inf], keep order:false                                                                               |
+------------------------------+-----------+------+----------------------------------------------------------------------------------------------------------------------------+
9 rows in set (0.00   sec)

可以看到，收集完统计信息后，现在的执行计划走了索引扫描，与手动添加 hint 的行为一致，且扫描的行数 757743 符合预期。

此时执行时间变为 1.69s ，在执行计划没变的情况下，应该是由于缓存命中率上升带来的提升。

mysql> select   count(*)
    -> from tods.bus_jijin_trade_record a,   tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code  and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and   a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and   a.id >=  177045000  
    -> and a.updated_at >   date_sub(now(), interval 48 hour) ;
+----------+
| count(*) |
+----------+
|      712 |
+----------+
1 row in set (1.69   sec)

案例总结

可以看出该 SQL 执行效率变差是由于统计信息不准确造成的，在通过收集统计信息之后得到了正确的执行计划。

从最终结果 712 行记录来看，创建联合索引可以更大的降低扫描数据的量，更进一步提升性能。在性能已经满足业务要求情况下，联合索引会有额外的成本，留待以后尝试。

本文为「TiDB 查询优化及调优」系列文章的第五篇，也是最终篇。通过这个系列文章，我们详细介绍了 TiDB 优化器、查询计划、慢查询以及调优的理论知识，并在本章节中进行了实战的分享。希望通过这个系列文章，大家能够更加深入地理解 TiDB 优化器，并通过这些调优技巧更好地提升系统性能。

如果您对 TiDB 的产品有任何建议，欢迎来到 internals.tidb.io 与我们交流。

TiDB_PingCAP
关注
博客
分布式数据库的进度管理：TiDB 备份恢复工具 PiTR 的原理与实践
10-09 1196
如果某个 TiKV 的 Checkpoint 因为种种原因一直没有成功推进，就会阻塞住 Global Checkpoint 的推进，进而可能阻塞住 GC，无法正确清除已经完成备份的冗余数据。对于单个 Region，可以通过记录已备份数据的时间戳来实现进度管理：当数据被刷盘时，记录当前时间戳，这个时间戳就是该 Region 完成备份的最小时间节点，即 Checkpoint。同时，我们需要了解到，需要备份的数据并不会永恒的保留。如果我们希望管理备份工作的具体进度，首先需要了解的是，备份工作究竟是怎样完成的。
博客
TiDB 优化器丨执行计划和 SQL 算子解读最佳实践
10-09 1269
导读在数据库系统中，查询优化器是数据库管理系统的核心组成部分，负责将用户的 SQL 查询转化为高效的执行计划，因而会直接影响用户体感的性能与稳定性。优化器的设计与实现过程充满挑战，有人比喻称这是数据库技术要持续攀登的珠穆朗玛峰，永远没有最优的止境。在一般的数据库系统中，查询优化涉及复杂的算法和数据结构，需要综合考虑多种因素，如数据分布、索引选择、连接顺序等，这些因素直接影响查询的性能和资源利用率。优化器在 HTAP（Hybrid Transactional and Analytical Processi
博客
平凯星辰亮相 2024开放原子开源生态大会，分享开源教育及社区治理经验
10-09 698
9 月 25-27 日，2024 开放原子开源生态大会在北京成功举办，本次大会以“开源赋能产业，生态共筑未来”为主题，由开放原子开源基金会主办，聚焦地方开源实践、企业开源建设思路，围绕开源生态建设，突出人工智能、云原生等重点领域，探索开源技术促进产业升级，塑造未来开源发展的新蓝图。熊岚曦表示，企业和基金会的紧密合作可以更有效地推动开源项目的成功，并培养出更多的开源人才。，由首席讲师董菲领衔授课。未来，平凯星辰将加强与开放原子开源基金会的合作，推动开源教育的普及，培养更多优秀人才，为开源社区贡献力量。
博客
瓜子二手车 x TiDB 丨平均耗时降低 30%，TiDB HTAP 在瓜子二手车财务中台结账核心系统的深度实践
09-25 1069
财务中台是连接业务系统与账务系统的中间枢纽，上游对接集团所有业务系统，将业务数据转化为财务视角的数据，从而实现集团层面的业财一体化。同时财务中台可以对线上财务数据进行统一管理与输出，不仅提升了财务月结工作时效，还可以通过财务视角对企业经营状况进行分析，支撑业务决策。系统架构财务中台分为数据接入、标准单据、核心计算、数据输出四个主模块，整体以配置为主，通过配置形式应用上下游业务变化，同时解放技术人员，完全由业务或者运营人员负责业务的对接和数据的转换。
博客
知乎 PB 级别 TiDB 数据库在线迁移实践
09-25 4539
通过三个月的迁移，我们将几十套 TiDB 集群，总量 PB 级数据，通过以上各种方式，安全稳定的迁移到了新机房，在此期间，我们根据迁移方案，也开发了平台化的 DTS ，以及机房迁移模块跟进迁移进度。
博客
TiDB 扩容过程中 PD 生成调度的原理及常见问题丨TiDB 扩缩容指南（一）
09-14 673
我们期望是将 store-3 上的 follower 迁移到 store-4 上，因此，在这一步骤，我们会将 store-4 和 store-3 上的副本的角色互换，最终 store-3 上的老副本会变成 learner, 而新节点上的副本角色变成 voter 也就是 follower.这个过程为了保证数据的安全性，实际情况分为两条调度指令执行。在扩容后，要做到整个集群的资源的快速均匀，一般跟我们 region 的数量、size 有直接关系，当然与我们集群的繁忙程度也有关系。
博客
基于 TiDB 资源管控 + TiCDC 实现多业务融合容灾测试
09-05 990
本文通过模拟环境测试验证，基于 TiDB 的资源管控能力可以实现多业务融合方案，通过给不同的业务系统分配不同的资源组，实现多套业务共享一套集群资源并且相互之间资源隔离的效果。基于 TiCDC 同步工具可以实现 TiDB 主备集群容灾，通过给不同的业务创建不同的同步链路，多个业务之间的主备同步流程互不干扰。结合资源管控及 TiCDC，我们可以实现一套多业务融合的容灾解决方案，能够满足企业客户尤其是金融机构同时具有多业务融合、容灾能力以及支持单体应用容灾切换演练等方面的需求。
博客
分布式数据库系统环境的“无感”升级
09-05 597
所有节点的连接平衡后，再进行下一组节点的操作。其间，使用数据库管理工具可添加准备下线存储节点的 Leader 角色的排斥调度，当同一数据分片 Raft 组的 Leader 角色切换到其他存储节点的数据副本后，计算节点的读写流量会随之调拨。多副本组成的 Raft 组可容忍少数派的副本成员下线，所以仅有 Follower 角色数据分片的节点进行升级重启时对业务无影响，且同一副本成员节点恢复后，将自动保持副本同步状态，管理员可通过管理工具恢复 Leader 角色的调度能力。单次滚动集群组件的批次设计见表 2。
博客
PingCAP 孙晓光：TiDB Cloud Serverless 将成为 AI 应用创新的最佳搭档
08-28 871
同时，TiDB Cloud Serverless 建立在开源的 TiDB 内核基础上，如果你对某些功能不满意，或者想要了解功能的实现方式，代码是开放的，可以自行探索；**换句话说，如果你有一个线上数据库，并且希望为每个开发者或每个小的功能迭代快速获得一个与环境完全一致的数据库，或者你的 Data Service 希望使用与当前版本完全一致的数据源进行开发测试，你可以通过 GitHub 上的 GitHub Actions Integration 来使用 Data Branch 功能。，使其更加易于使用。
博客
VLDB 2024丨与 TiDB 一起探索数据库学术前沿
08-28 1102
在数据分析日益重要的今天，表格问答（TQA）技术正逐渐成为研究的热点。然而，现有的 TQA 方法主要处理单表问题，而现实世界中的 TQA 问题通常涉及多个表格，这带来了扩展性的挑战。为了解决这一问题，我们提出了 AutoTQA，一个自主的多表格问答框架，它利用多智能体大型语言模型（LLMs）来处理来自不同系统（如 TiDB, BigQuery）的多个表格。AutoTQA 由五个智能体组成：用户智能体接收自然语言查询，规划智能体创建执行计划，工程师智能体执行计划，执行智能体提供执行环境，批判智能体评估结果。
博客
PingCAP 携手 CCF 数据库专委会打造“开源数据库领域拔尖创新人才培育计划”，共塑数据库教育未来丨NDBC 2024
08-21 472
2024 年 8 月 7 日 - 10 日，由中国计算机学会主办、中国计算机学会数据库专业委员会和新疆大学承办、新疆 IT 三会等单位协办的第 41 届中国数据库学术会议（NDBC 2024）在新疆乌鲁木齐成功举办。
博客
SHOPLINE x TiDB丨集群成本降低 50%！跨境电商 SHOPLINE 交易、商品管理等核心业务的数据库升级之路
08-21 793
SHOPLINE 是一家提供一站式跨境电商解决方案的公司，专注于帮助企业和个人在全球范围内建立和发展他们的在线业务。SHOPLINE 提供的服务包括但不限于在线商店搭建、多渠道销售、库存管理、支付系统整合、物流跟踪、营销工具以及客户关系管理等。通过这些服务，SHOPLINE 旨在帮助商家轻松管理他们的在线销售和客户关系，同时提供必要的技术支持和数据分析，以优化业务运营和提高转化率。
博客
全球化浪潮下的数据库革新：嘉里物流 TiDB 实践价值的设想
08-10 1071
随着全球化业务的不断扩展和数据量的爆炸性增长，设想以 TiDB 为技术架构和数据架构的核心，能够有效的进行数据整合，同时帮助推进应用架构和业务架构的改善和发展，收敛和逐渐合并技术栈，减少相应的学习成本和运维成本，并且能够帮助缩小各个业务线之间集成难度。TiDB 技术架构能够帮助企业实现降本增效的目标，开源社区在推动技术创新和知识共享中也将起到重要作用。我期待 TiDB 在未来能够继续发展和完善，为更多的企业提供强大的数据管理和分析能力；
博客
从 MySQL 迁移到 TiDB：使用 SQL-Replay 工具进行真实线上流量回放测试 SOP
08-10 1258
1.1 工具简介SQL-Replay 工具是一个设计用于回放 MySQL 慢查询文件和 parse-tshark 抓包文件的 GitHub 开源项目，目的是帮助评估数据库兼容性和性能。这个工具支持多种操作模式，包括解析慢查询日志、回放这些日志、将回放结果加载到数据库中以及生成报告。1.2 原理概述a. MySQL 的慢日志文件以及通过 parse-tshark 抓包生成的文件，这些日志中包括 SQL 执行时间、SQL 文本。
博客
PingCAP 崔秋当选 CCF 数据库专业委员会执行委员
08-10 336
崔秋表示：“作为一名开源基础软件公司的联合创始人，我深知产学研结合的重要性。我相信，通过 CCF 的支持和帮助，PingCAP 可以在产学研结合和人才培养方面发挥更大的作用，为国内数据库技术的发展贡献力量。作为新任执委，崔秋计划进一步推动产学研结合，推进设立并推动“开源数据库领域拔尖创新人才培育计划”，以人才培养为核心，建立开放、共享、协作的开源数据库学习型社区，以 Talent Plan 开源社区运营为核心开始全新的合作，共同开展开源治理、课程共建、人才培养等工作，用开源的方式培养更多的开源人才。
博客
TiKV Raft 快照全流程丨TiKV 源码解读（二十二）
08-04 908
这个快照包含了 Region 在某一特定时间点的完整状态快照，不仅包括存储于 RocksDB 中的数据，还有 Raft 协议的状态信息，例如任期号（term）和所对应的日志索引（index）。Raft leader 在 maybe_send_append 中处理某个 Follower 的 Append RPC 的发送，如果它无法获取前置日志（pr.next_idx - 1）的任期（用于 Append 过程的匹配校验），则需要发送快照。这是为了控制快照生成的时间点，让快照尽可能地包含最新的数据。
博客
蔚来汽车 x TiDB丨单表超 20 亿条数据，从 MySQL 到 TiDB 的迁移思考与实践
08-04 937
*8. 丰富的生态系统：**TiDB 拥有一个成熟的生态系统，包括 TiFlash 提供的列式存储引擎，优化了分析型查询的性能；**6. 灵活的分区功能：**TiDB 提供了灵活的分区机制，支持 hash、range、list、key 等分区，简化了数据管理和维护工作，使得业务逻辑与数据分片解耦，提高了查询效率。通过这些特性，TiDB 不仅为蔚来提供了一个高性能、高可用的数据库解决方案，还通过其强大的生态系统，支持蔚来在数据管理和分析方面的需求，推动了业务的持续创新和发展。
博客
TiDB Hackathon 2024丨用 TiDB 构建未来的 AI 创新应用， 瓜分超 ￥210,000 奖金池！
07-25 1039
TiDB Serverless 是一款超轻量级、完全托管的 MySQL 兼容数据库，提供自动扩缩容、HTAP（混合事务和分析处理）能力，并内置向量搜索功能。值得一提的是，TiDB Serverless 将大大简化你的 AI 应用开发流程，只需点击几下，即可部署和配置一个具备完整功能的 Serverless TiDB 数据库！
博客
平凯星辰亮相 2024 中国国际金融展，发布银行交易明细查询白皮书
07-25 658
同时，数据库需要具备高效的同城双活灾备方案，以保障在灾难情况下系统的稳定性和数据的安全性。查询方式的多样化、时间跨度的灵活性和效率的实时性对查询系统的数据存储和计算提出了更高的要求。《场景解决方案白皮书——银行领域交易明细查询》在分析历史明细查询数据库架构的基础上，重点介绍了基于 TiDB 分布式数据库的新一代交易明细查询解决方案，分享了中国头部金融机构的应用实践，旨在为银行及其他金融机构在构建新一代分布式核心系统和统一查询平台过程中提供深度洞察和实用参考，助力金融机构充分挖掘数据潜力，显著提升用户体验。
博客
杭州银行 x 平凯星辰 TiDB “行领柜面系统”荣获 2024 “金鼎奖”
07-25 277
作为杭州银行新一代核心系统关联度高的另一自主研发的关键业务系统，“行领柜面系统” 是业内首家采用移动端平板作为柜面主体设备的银行柜面系统。在外设层面，系统通过标准化客户端和外设的协议接口，实现通用的软硬件交互方案，利用悬臂支架和拓展坞集成化管理柜面高拍仪，扫码枪，结构光摄像头，读卡器等常用外设，在简化柜面空间的同时，节约了多种厂商设备的对接开发成本。，极大提升客户体验。同时，通过数据埋点，结合 AI、大数据分析等技术，系统可以形成精准的客户画像和专业知识库，为柜员更好地开展各项业务活动保驾护航。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值