PolarDB-X 1.0-用户指南-自定义控制指令-SQL 调优类语句

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 本文汇总了PolarDB-X支持的SQL调优类语句。

本文汇总了PolarDB-X支持的SQL调优类语句。

1. SHOW [FULL] SLOW [WHERE expr] [limit expr]

执行时间超过 1 秒的 SQL 语句是慢 SQL,逻辑慢 SQL 是指应用发送到 PolarDB-X 的慢 SQL。关于如何排查慢SQL,详情请参见排查慢SQL

  • SHOW SLOW: 查看自 PolarDB-X 启动或者上次执行CLEAR SLOW以来最慢的 100 条逻辑慢 SQL(注意,这里记录的是最慢的 100 个,缓存在 PolarDB-X 系统中,当实例重启或者执行 CLEAR SLOW 时会丢失);
  • SHOW FULL SLOW: 查看实例启动以来记录的所有逻辑慢 SQL(持久化到 PolarDB-X 的内置数据库中)。该记录数有一个上限(具体数值跟购买的实例规格相关),PolarDB-X 会滚动删除比较老的慢 SQL 语句。实例的规格如果是 4C4G 的话,最多记录 10000 条慢 SQL 语句(包括逻辑慢 SQL 和物理慢 SQL);实例的规格如果是 8C8G 的话,最多记录 20000 条慢 SQL 语句(包括逻辑慢 SQL 和物理慢 SQL),其它规格依此类推。

重要列详解:

  • HOST:来源 IP;
  • START_TIME:执行开始时间;
  • EXECUTE_TIME:执行时间;
  • AFFECT_ROW:对于 DML 语句是影响行数;对于查询语句是返回的记录数。


  1. mysql> show slow where execute_time >1000 limit 1;
  2. +-----------+---------------------+--------------+------------+-----------+
  3. | HOST      | START_TIME          | EXECUTE_TIME | AFFECT_ROW | SQL       |
  4. +-----------+---------------------+--------------+------------+-----------+
  5. |127.0.0.1|2016-03-1613:02:57|         2785|          7| show rule |
  6. +-----------+---------------------+--------------+------------+-----------+
  7. 1 row inset(0.02 sec)

2. SHOW [FULL] PHYSICAL_SLOW [WHERE expr] [limit expr]

执行时间超过1秒的 SQL 语句是慢 SQL,物理慢 SQL 是指 PolarDB-X 发送到 RDS 的慢 SQL。关于如何排查慢SQL,详情请参见排查慢SQL

  • SHOW PHYSICAL_SLOW: 查看自 PolarDB-X 启动或者上次执行CLEAR SLOW以来最慢的 100 条物理慢 SQL(注意,这里记录的是最慢的 100 个,缓存在 PolarDB-X 系统中,当实例重启或者执行 CLEAR SLOW 时会丢失);
  • SHOW FULL PHYSICAL_SLOW: 查看实例启动以来记录的所有物理慢 SQL(持久化到 PolarDB-X 的内置数据库中)。该记录数有一个上限(具体数值跟购买的实例规格相关),PolarDB-X 会滚动删除比较老的慢 SQL 语句。实例的规格如果是 4C4G 的话,最多记录 10000 条慢 SQL 语句(包括逻辑慢 SQL 和物理慢 SQL);实例的规格如果是 8C8G 的话,最多记录 20000 条慢 SQL 语句(包括逻辑慢 SQL 和物理慢 SQL),其它规格依此类推。

重要列详解:

  • GROUP_NAME:数据库分组;
  • START_TIME:执行开始时间;
  • EXECUTE_TIME:执行时间;
  • AFFECT_ROW:对于 DML 语句是影响行数;对于查询语句是返回的记录数。


  1. mysql> show physical_slow;
  2. +----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+
  3. | GROUP_NAME     | DBKEY_NAME                        | START_TIME          | EXECUTE_TIME | SQL_EXECUTE_TIME | GETLOCK_CONNECTION_TIME | CREATE_CONNECTION_TIME | AFFECT_ROW | SQL             |
  4. +----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+
  5. | TDDL5_00_GROUP | db218249098_sqa_zmf_tddl5_00_3309 |2016-03-1613:05:38|         1057|             1011|                       0|                      0|          1|select sleep(1)|
  6. +----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+
  7. 1 row inset(0.01 sec)

3. CLEAR SLOW

清空自PolarDB-X启动或者上次执行CLEAR SLOW以来最慢的100条逻辑慢SQL和最慢的100条物理慢 SQL。

SHOW SLOWSHOW PHYSICAL_SLOW展示的是最慢的100个SQL,如果长时间未执行CLEAR SLOW,可能都是非常老的SQL了。一般执行过SQL优化之后,建议都执行下CLEAR SLOW,等待系统运行一段时间,再查看慢SQL的优化效果。


  1. mysql> clear slow;
  2. Query OK,0 rows affected (0.00 sec)

4. EXPLAIN SQL

查看指定 SQL 在 PolarDB-X 层面的执行计划,注意这条 SQL 不会实际执行。关于该指令的更多案例,详情请参见SQL优化基本概念SQL优化方法

示例:

查看select * from doctest这条 SQL 的执行计划(doctest 这张表是按照ID列进行分库的)。从执行计划可以看出该 SQL 会下推到每个分库,然后将执行结果聚合。


  1. mysql> explain select*from doctest;
  2. +------------------------------------------------+--------------------------------------+--------+
  3. | GROUP_NAME                                     | SQL                                  | PARAMS |
  4. +------------------------------------------------+--------------------------------------+--------+
  5. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0000_RDS |select`doctest`.`id`from`doctest`|{}     |
  6. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0001_RDS |select`doctest`.`id`from`doctest`|{}     |
  7. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0002_RDS |select`doctest`.`id`from`doctest`|{}     |
  8. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0003_RDS |select`doctest`.`id`from`doctest`|{}     |
  9. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0004_RDS |select`doctest`.`id`from`doctest`|{}     |
  10. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0005_RDS |select`doctest`.`id`from`doctest`|{}     |
  11. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0006_RDS |select`doctest`.`id`from`doctest`|{}     |
  12. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0007_RDS |select`doctest`.`id`from`doctest`|{}     |
  13. +------------------------------------------------+--------------------------------------+--------+
  14. 8 rows inset(0.00 sec)

查看select * from doctest where id = 1这条 SQL 的执行计划(doctest 这张表是按照ID列进行分库的)。从执行计划可以看出该 SQL 会根据拆分键(ID)计算出具体的分库,将 SQL 直接下推到该分库,然后执行结果聚合。


  1. mysql> explain select*from doctest where id =1;
  2. +------------------------------------------------+-----------------------------------------------------------------+--------+
  3. | GROUP_NAME                                     | SQL                                                             | PARAMS |
  4. +------------------------------------------------+-----------------------------------------------------------------+--------+
  5. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0001_RDS |select`doctest`.`id`from`doctest`where(`doctest`.`id`=1)|{}     |
  6. +------------------------------------------------+-----------------------------------------------------------------+--------+
  7. 1 row inset(0.01 sec)

5. EXPLAIN DETAIL SQL

查看指定 SQL 在 PolarDB-X 层面的执行计划。注意这条 SQL 不会实际执行。关于该指令的更多案例,详情请参见SQL优化基本概念SQL优化方法


  1. mysql> explain detail select*from doctest where id =1;
  2. +------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+
  3. | GROUP_NAME                                     | SQL                                                                                                                                                                                                     | PARAMS |
  4. +------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+
  5. | DOCTEST_1488704345426RCUPDOCTEST_CAET_0001_RDS |Queryfrom doctest as doctest
  6.    keyFilter:doctest.id =1
  7.    queryConcurrency:SEQUENTIAL
  8.    columns:[doctest.id]
  9.    tableName:doctest
  10.    executeOn:DOCTEST_1488704345426RCUPDOCTEST_CAET_0001_RDS
  11. | NULL   |
  12. +------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+
  13. 1 row inset(0.02 sec)

6. EXPLAIN EXECUTE SQL

查看底层存储的执行计划,等同于 MYSQL 的 EXPLAIN 语句。关于该指令的更多案例,详情请参见SQL优化基本概念SQL优化方法


  1. mysql> explain execute select*from tddl_mgr_log limit 1;
  2. +----+-------------+--------------+------+---------------+------+---------+------+------+-------+
  3. | id | select_type | table        | type | possible_keys | key  | key_len |ref  | rows |Extra|
  4. +----+-------------+--------------+------+---------------+------+---------+------+------+-------+
  5. |  1| SIMPLE      | tddl_mgr_log | ALL  | NULL          | NULL | NULL    | NULL |    1| NULL  |
  6. +----+-------------+--------------+------+---------------+------+---------+------+------+-------+
  7. 1 row inset(0.07 sec)

7. TRACE SQL 和 SHOW TRACE

查看具体 SQL 的执行情况。TRACE [SQL] 和 SHOW TRACE 要结合使用。注意 TRACE SQL 和 EXPLAIN SQL 的区别在于 TRACE SQL 会实际执行该语句。关于该指令的更多案例,详情请参见SQL优化基本概念SQL优化方法

例如查看 select 1这条语句的执行情况。


  1. mysql> trace select1;
  2. +---+
  3. |1|
  4. +---+
  5. |1|
  6. +---+
  7. 1 row inset(0.03 sec)
  8. mysql> show trace;
  9. +------+----------+----------------+-----------------------------------+---------------+--------------------------+------+-----------+--------+
  10. | ID   | TYPE     | GROUP_NAME     | DBKEY_NAME                        | TIME_COST(MS)| CONNECTION_TIME_COST(MS)| ROWS | STATEMENT | PARAMS |
  11. +------+----------+----------------+-----------------------------------+---------------+--------------------------+------+-----------+--------+
  12. |    0|Optimize| DRDS           | DRDS                              |3             |0.00                     |    0|select1  | NULL   |
  13. |    1|Query    | TDDL5_00_GROUP | db218249098_sqa_zmf_tddl5_00_3309 |7             |0.15                     |    1|select1  | NULL   |
  14. +------+----------+----------------+-----------------------------------+---------------+--------------------------+------+-----------+--------+
  15. 2 rows inset(0.01 sec)

8. CHECK TABLE tablename

对数据表进行检查。主要用于 DDL 建表失败的情形,关于更多应用案例详情,请参见DDL常见问题处理

  • 对于拆分表,检查底层物理分表是否有缺失的情况,底层的物理分表的列和索引是否是一致;
  • 对于单库单表,检查表是否存在。


  1. mysql>  check table tddl_mgr_log;
  2. +------------------------+-------+----------+----------+
  3. | TABLE                  | OP    | MSG_TYPE | MSG_TEXT |
  4. +------------------------+-------+----------+----------+
  5. | TDDL5_APP.tddl_mgr_log | check | status   | OK       |
  6. +------------------------+-------+----------+----------+
  7. 1 row inset(0.56 sec)
  8. mysql> check table tddl_mg;
  9. +-------------------+-------+----------+----------------------------------------+
  10. | TABLE             | OP    | MSG_TYPE | MSG_TEXT                               |
  11. +-------------------+-------+----------+----------------------------------------+
  12. | TDDL5_APP.tddl_mg | check |Error    |Table'tddl5_00.tddl_mg' doesn't exist |
  13. +-------------------+-------+----------+----------------------------------------+
  14. 1 row in set (0.02 sec)

9. SHOW TABLE STATUS [LIKE ‘pattern’ | WHERE expr]

获取表的信息,该指令聚合了底层各个物理分表的数据。

重要列详解:

  • NAME:表名称;
  • ENGINE:表的存储引擎;
  • VERSION:表的存储引擎的版本;
  • ROW_FORMAT:行格式,主要是 Dynamic、Fixed、Compressed 这三种格式。动态(Dynamic)行的行长度可变,例如 VARCHAR 或 BLOB 类型字段;固定(Fixed)行是指行长度不变,例如CHAR和INTEGER类型字段;
  • ROWS:表中的行数;
  • AVG_ROW_LENGTH:平均每行包括的字节数;
  • DATA_LENGTH:整个表的数据量(单位:字节);
  • MAX_DATA_LENGTH:表可以容纳的最大数据量;
  • INDEX_LENGTH:索引占用磁盘的空间大小 ;
  • CREATE_TIME:表的创建时间;
  • UPDATE_TIME:表的最近更新时间;
  • COLLATION:表的默认字符集和字符排序规则;
  • CREATE_OPTIONS:指表创建时的其他所有选项。


  1. mysql> show table status like 'multi_db_multi_tbl';
  2. +--------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-----------------------+-------------+------------+-----------------+----------+----------------+---------+
  3. | NAME               | ENGINE | VERSION | ROW_FORMAT | ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME           | UPDATE_TIME | CHECK_TIME | COLLATION       | CHECKSUM | CREATE_OPTIONS | COMMENT |
  4. +--------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-----------------------+-------------+------------+-----------------+----------+----------------+---------+
  5. | multi_db_multi_tbl |InnoDB|      10|Compact    |    2|          16384|       16384|               0|        16384|         0|         100000|2017-03-2717:43:57.0| NULL        | NULL       | utf8_general_ci | NULL     |                |         |
  6. +--------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-----------------------+-------------+------------+-----------------+----------+----------------+---------+
  7. 1 row inset(0.03 sec)

和 PolarDB-X 的 SCAN HINT 结合,还可以查看每个物理分表的数据量。详情请参见HINT语法


  1. mysql>/!TDDL:SCAN='multi_db_multi_tbl'*/show table status like 'multi_db_multi_tbl';
  2. +----------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+--------------+
  3. |Name                 |Engine|Version|Row_format|Rows|Avg_row_length|Data_length|Max_data_length|Index_length|Data_free|Auto_increment|Create_time         |Update_time|Check_time|Collation       |Checksum|Create_options|Comment|Block_format|
  4. +----------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+--------------+
  5. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  6. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  7. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  8. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    1|          16384|       16384|               0|        16384|         0|              2|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  9. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  10. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  11. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  12. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  13. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  14. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  15. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  16. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  17. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  18. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  19. | multi_db_multi_tbl_1 |InnoDB|      10|Compact    |    0|              0|       16384|               0|        16384|         0|              1|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  20. | multi_db_multi_tbl_0 |InnoDB|      10|Compact    |    1|          16384|       16384|               0|        16384|         0|              3|2017-03-2717:43:57| NULL        | NULL       | utf8_general_ci |     NULL |                |         |Original     |
  21. +----------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+--------------+
  22. 16 rows inset(0.04 sec)
相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
3月前
|
SQL Java 测试技术
3、Mybatis-Plus 自定义sql语句
这篇文章介绍了如何在Mybatis-Plus框架中使用自定义SQL语句进行数据库操作。内容包括文档结构、编写mapper文件、mapper.xml文件的解释说明、在mapper接口中定义方法、在mapper.xml文件中实现接口方法的SQL语句,以及如何在单元测试中测试自定义的SQL语句,并展示了测试结果。
3、Mybatis-Plus 自定义sql语句
|
6天前
|
SQL 缓存 Java
【详细实用のMyBatis教程】获取参数值和结果的各种情况、自定义映射、动态SQL、多级缓存、逆向工程、分页插件
本文详细介绍了MyBatis的各种常见用法MyBatis多级缓存、逆向工程、分页插件 包括获取参数值和结果的各种情况、自定义映射resultMap、动态SQL
【详细实用のMyBatis教程】获取参数值和结果的各种情况、自定义映射、动态SQL、多级缓存、逆向工程、分页插件
|
16天前
|
SQL 数据库 开发者
功能发布-自定义SQL查询
本期主要为大家介绍ClkLog九月上线的新功能-自定义SQL查询。
|
3月前
|
前端开发 开发者
Vaadin Grid的秘密武器:打造超凡脱俗的数据展示体验!
【8月更文挑战第31天】赵萌是一位热爱UI设计的前端开发工程师。在公司内部项目中,她面临大量用户数据展示的挑战,并选择了功能强大的Vaadin Grid来解决。她在技术博客上分享了这一过程,介绍了Vaadin Grid的基本概念及其丰富的内置功能。通过自定义列和模板,赵萌展示了如何实现复杂的数据展示。
41 0
|
3月前
|
SQL 开发框架 .NET
深入解析Entity Framework Core中的自定义SQL查询与Raw SQL技巧:从基础到高级应用的全面指南,附带示例代码与最佳实践建议
【8月更文挑战第31天】本文详细介绍了如何在 Entity Framework Core (EF Core) 中使用自定义 SQL 查询与 Raw SQL。首先,通过创建基于 EF Core 的项目并配置数据库上下文,定义领域模型。然后,使用 `FromSqlRaw` 和 `FromSqlInterpolated` 方法执行自定义 SQL 查询。此外,还展示了如何使用 Raw SQL 进行数据更新和删除操作。最后,通过结合 LINQ 和 Raw SQL 构建动态 SQL 语句,处理复杂查询场景。本文提供了具体代码示例,帮助读者理解和应用这些技术,提升数据访问层的效率和灵活性。
182 0
|
4月前
|
SQL Java 数据库连接
idea中配置mybatis 映射文件模版及 mybatis plus 自定义sql
idea中配置mybatis 映射文件模版及 mybatis plus 自定义sql
87 3
|
4月前
|
SQL DataWorks 关系型数据库
DataWorks产品使用合集之数据集成时源头提供数据库自定义函数调用返回数据,数据源端是否可以写自定义SQL实现
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
4月前
|
SQL
常用工具类---SQL工具,HTTP工具
SQL工具,HTTP工具,两个实用小工具~~~
|
25天前
|
关系型数据库 MySQL 分布式数据库
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶,邀请好友完成更有机会获得​小米Watch S3、小米体重称​等诸多好礼!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
|
2月前
|
关系型数据库 MySQL Serverless
探索PolarDB MySQL版:Serverless数据库的灵活性与性能
本文介绍了个人开发者对阿里云PolarDB MySQL版,特别是其Serverless特性的详细评测体验。评测涵盖了产品初体验、性能观测、Serverless特性深度评测及成本效益分析等方面。尽管试用过程中遇到一些小问题,但总体而言,PolarDB MySQL版表现出色,提供了高性能、高可用性和灵活的资源管理,是个人开发者和企业用户的优秀选择。

相关产品

  • 云原生分布式数据库 PolarDB-X
  • 下一篇
    无影云桌面