AI 助理
备案控制台
开发者社区 PolarDB开源 PolarDB 分布式版 文章 正文

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

2021-10-29 298
版权
举报
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云原生数据库 PolarDB 分布式版，标准版 2核8GB
推荐场景：
使用PolarDB-X与Flink搭建实时数据大屏
简介： 本文汇总了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 SLOW和SHOW 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-X
云数据库 RDS MySQL 版
SQL
关系型数据库
索引
MySQL
RDS
数据库
存储
分布式数据库
数据库连接
关键词：
云原生分布式数据库 PolarDB-X sql
云原生数据库 PolarDB sql
SQL调优
云原生数据库 PolarDB自定义
SQL类
相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库：PolarDB PostgreSQL版和PolarDB分布式版，支持一键拉起使用，方便各位开发者学习使用。
码农小达人
+关注
1621文章
目录
打赏
0
0
0
0
153
分享
相关文章
DatabaseEvangelist
|
5月前
|
SQL 关系型数据库 分布式数据库
利用 PolarDB PG 版向量化引擎，加速复杂 SQL 查询！完成任务领发财新年抱枕！
利用 PolarDB PG 版向量化引擎，加速复杂 SQL 查询！完成任务领发财新年抱枕！
DatabaseEvangelist
163 14
威哥爱编程
|
6月前
|
SQL Java 数据库连接
如何在 Java 代码中使用 JSqlParser 解析复杂的 SQL 语句？
大家好，我是 V 哥。JSqlParser 是一个用于解析 SQL 语句的 Java 库，可将 SQL 解析为 Java 对象树，支持多种 SQL 类型（如 `SELECT`、`INSERT` 等）。它适用于 SQL 分析、修改、生成和验证等场景。通过 Maven 或 Gradle 安装后，可以方便地在 Java 代码中使用。
威哥爱编程
1979 11
游客54bz4h3flp7ai
|
8月前
|
SQL 存储 BI
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
游客54bz4h3flp7ai
114 1
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之遇到SQL语法错误，该如何排查
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
285 0
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之遇到慢SQL问题，该如何解决
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
313 7
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之出现部分SQL抛出7543错误，该如何解决
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
117 1
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之sql运行报错是神么原因
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
135 3
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 缓存 关系型数据库
PolarDB产品使用问题之SQL语句是否可以参数化
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
68 1
嘟嘟嘟嘟嘟嘟
|
12月前
|
SQL 关系型数据库 Serverless
PolarDB产品使用问题之如何控制队列中排队的SQL的等待时间
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
79 3
嘟嘟嘟嘟嘟嘟
|
关系型数据库 分布式数据库 数据库
PolarDB产品使用问题之将RDS切换到PolarDB-X 2.0时，代码层的SQL该如何改动
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务，旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境，满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能，实现数据库的高效运维与持续优化。
嘟嘟嘟嘟嘟嘟
143 3
PolarDB开源

PolarDB 分布式版
+关注

热门文章

最新文章

  • 1
    PolarDB-X 开源 | 基于Paxos的MySQL三副本
    20
  • 2
    PolarDB-X 存储引擎核心技术 | Lizard分布式事务系统
    15
  • 3
    Java“Bad Magic Number”错误解决
    15
  • 4
    kubeblocks完成阿里云PolarDB数据库产品生态集成认证
    13
  • 5
    k8s 部署polardb-x集群
    12
  • 6
    PolarDB-X Operator 基于两次心跳事务的指定时间点恢复方案介绍
    11
  • 7
    最佳实践—如何分析及优化慢SQL
    11
  • 8
    [重磅更新]PolarDB-X V2.3 集中式和分布式一体化开源发布
    10
  • 9
    深度优化 | PolarDB-X 基于向量化SIMD指令的探索
    9
  • 10
    PolarDB-X 分布式数据库中的外键
    9
  • 1
    Java“Bad Magic Number”错误解决
    517
  • 2
    k8s 部署polardb-x集群
    530
  • 3
    PolarDB-X 存储引擎核心技术 | Lizard B+tree 优化
    7721
  • 4
    PolarDB-X的TPC-H列存执行计划
    8198
  • 5
    让X不断延伸, 从跨AZ到跨Region再到跨Cloud
    8556
  • 6
    PolarDB-X 存储引擎核心技术 | Lizard 多级闪回
    504
  • 7
    开源PolarDB-X部署体验：挑战与反思
    464
  • 8
    开源PolarDB-X部署体验：探索与反馈
    508
  • 9
    PolarDB-X 原生无锁变更，比 gh-ost 更快、更稳定
    417
  • 10
    PolarDB-X 存储引擎核心技术 | Lizard 无锁备份
    345

    • 相关产品

  • 云原生分布式数据库 PolarDB-X
    文档详情 产品详情

    • 相关课程

    更多
  • 如何在 PolarDB-X 中进行 Online DDL
  • 如何对 PolarDB-X 集群做动态扩缩容
  • 如何将 PolarDB-X 与大数据等系统互通
  • 如何使用 PolarDB-X
  • 如何一键安装部署 PolarDB-X
  • PolarDB-X 动手实践

    • 相关电子书

    更多
  • PolarDB-X分布式数据库解决方案
  • PolarDB-X 2.0 全局 Binlog 与备份恢复能
  • 分布式数据库DRDS全新升级

    • 相关实验场景

    更多
  • 一小时快速掌握SQL语法
  • 体验PolarDB-X透明分布式
  • PolarDB for AI：在数据库中通过SQL实现AI能力
  • 玩转MaxCompute SQL! 30分钟搞定数据分析挖掘
  • 使用SQL语句实现数据查询操作
  • 使用SQL语句管理索引
    • 下一篇
    快手商品数据采集神器，助你轻松获取商品详情数据
    AI助理

    你好，我是AI助理

    可以解答问题、推荐解决方案等