MySQL HeatWave 用户指南  / 第 2 章热浪  /  2.3 运行查询

2.3 运行查询

当启用 HeatWave 并加载要查询的数据时,符合条件的查询会自动从 MySQL 数据库系统卸载到 HeatWave 以加速处理。无需特殊操作。只需从连接到与 HeatWave 集群关联的数据库系统的客户端、应用程序或界面运行查询。在 HeatWave 处理查询后,结果将发送回 MySQL 数据库系统和发出查询的客户端、应用程序或接口。

有关连接到 OCI 上的 MySQL 数据库系统的信息,请参阅 MySQL 数据库服务指南中的连接到数据库系统。对于 AWS 上的 MySQL HeatWave,请参阅 MySQL HeatWave on AWS 服务指南中的 从客户端连接

以下部分介绍了运行查询和其他与查询相关的主题:

有关相关的最佳实践,请参阅 第 2.8 节“最佳实践”

查询先决条件

以下先决条件适用于将查询卸载到 HeatWave:

如果不满足任何先决条件,则查询不会卸载并默认回退到 MySQL 数据库系统进行处理。

运行查询

在运行查询之前,您可以使用 EXPLAIN确定查询是否将卸载到 HeatWave 进行处理。如果是,则 输出ExtraEXPLAIN显示: Using secondary engine RAPID

mysql> EXPLAIN SELECT O_ORDERPRIORITY, COUNT(*) AS ORDER_COUNT FROM orders 
       WHERE O_ORDERDATE >= DATE '1994-03-01' GROUP BY O_ORDERPRIORITY 
       ORDER BY O_ORDERPRIORITY\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: orders
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 14862970
     filtered: 33.33
        Extra: Using where; Using temporary; Using filesort; Using secondary 
        engine RAPID

如果Using secondary engine RAPID未出现在Extra列中,则查询不会卸载到 HeatWave。要确定查询不会卸载的原因,请参阅第 2.13 节“故障排除”,或尝试使用调试查询中描述的过程 调试查询

使用EXPLAIN验证查询可以卸载后,运行查询并记下执行时间。

mysql> SELECT O_ORDERPRIORITY, COUNT(*) AS ORDER_COUNT FROM orders 
       WHERE O_ORDERDATE >= DATE '1994-03-01' GROUP BY O_ORDERPRIORITY 
       ORDER BY O_ORDERPRIORITY;
+-----------------+-------------+
| O_ORDERPRIORITY | ORDER_COUNT |
+-----------------+-------------+
| 1-URGENT        |     2017573 |
| 2-HIGH          |     2015859 |
| 3-MEDIUM        |     2013174 |
| 4-NOT SPECIFIED |     2014476 |
| 5-LOW           |     2013674 |
+-----------------+-------------+
5 rows in set (0.04 sec)

要将 HeatWave 查询执行时间与 MySQL 数据库系统执行时间进行比较,请禁用 use_secondary_engine变量并再次运行查询以查看在 MySQL 数据库系统上运行需要多长时间。

mysql> SET SESSION use_secondary_engine=OFF;

mysql> SELECT O_ORDERPRIORITY, COUNT(*) AS ORDER_COUNT FROM orders 
       WHERE O_ORDERDATE >= DATE '1994-03-01' GROUP BY O_ORDERPRIORITY 
       ORDER BY O_ORDERPRIORITY;
+-----------------+-------------+
| O_ORDERPRIORITY | ORDER_COUNT |
+-----------------+-------------+
| 1-URGENT        |     2017573 |
| 2-HIGH          |     2015859 |
| 3-MEDIUM        |     2013174 |
| 4-NOT SPECIFIED |     2014476 |
| 5-LOW           |     2013674 |
+-----------------+-------------+
5 rows in set (8.91 sec)
笔记

同时发出的查询优先执行。有关查询优先级的信息,请参阅 自动计划

自动排程

HeatWave 使用工作负载感知、基于优先级的自动调度机制来调度并发发出的查询以供执行。调度机制优先考虑短期运行的查询,但考虑队列中的等待时间,以便最终安排执行成本更高的查询。这种调度方法总体上减少了查询执行等待时间。

当 HeatWave 空闲时,到达的查询会立即安排执行。它没有排队。仅当前面的查询在 HeatWave 上运行时,查询才会排队。

在查询编译时为每个查询执行轻量级成本估算。

通过取消的查询Ctrl-C将从调度队列中删除。

有关您可以运行以查看 HeatWave 查询历史记录(包括查询开始时间、结束时间和调度队列中的等待时间)的查询,请参阅第 5.2 节,“HeatWave 监控”

自动查询计划改进

当在 HeatWave 中执行查询时,自动查询计划改进功能会收集查询计划统计信息并将其存储在统计缓存中。当新查询与先前执行的查询共享查询执行计划节点时,将使用从先前执行的查询中收集的统计信息而不是估计的统计信息,从而改进查询执行计划、成本估计、执行时间和内存效率。

缓存中的每个条目对应一个查询执行计划节点。查询执行计划可能有用于表扫描、 JOINs、GROUP BY 操作等的节点。

统计缓存是一个LRU结构。当达到缓存容量时,随着新条目的添加,最近最少使用的条目将从缓存中逐出。统计缓存中允许的条目数为 65536,足以存储 4000 到 5000 个中等复杂度的唯一查询的统计信息。统计缓存条目的最大数量由 MySQL 管理的 rapid_stats_cache_max_entries 设置定义。

调试查询

本节介绍如何调试无法卸载到 HeatWave 以执行的查询。查询调试是通过启用 MySQL 优化器跟踪并查询 INFORMATION_SCHEMA.OPTIMIZER_TRACE 失败原因的表来执行的。

  1. 要启用 MySQL 优化器跟踪,请设置 optimizer_traceoptimizer_trace_offset 变量,如下所示:

    mysql> SET SESSION optimizer_trace="enabled=on";
    mysql> SET optimizer_trace_offset=-2;
  2. 使用 发出有问题的查询 EXPLAIN。如果 HeatWave 支持查询,Extra则输出中的列EXPLAIN显示以下文本:Using secondary engine RAPID;否则,该文本不会出现。以下查询示例使用了 TIMEDIFF()HeatWave 目前不支持的函数:

    mysql> EXPLAIN SELECT TIMEDIFF(O_ORDERDATE,'2000:01:01 00:00:00.000001') FROM orders\G
    *************************** 1. row ***************************
               id: 1
      select_type: SIMPLE
            table: ORDERS
       partitions: NULL
             type: ALL
    possible_keys: NULL
              key: NULL
          key_len: NULL
              ref: NULL
             rows: 1488248
         filtered: 100
            Extra: NULL
    1 row in set, 1 warning (0.0011 sec)
  3. 查询 INFORMATION_SCHEMA.OPTIMIZER_TRACE 表失败原因。对于卸载失败的查询,有两个跟踪标记:

    • Rapid_Offload_Fails

    • secondary_engine_not_used

    要查询Rapid_Offload_Fails 跟踪标记,请发出以下查询:

    SELECT QUERY, TRACE->'$**.Rapid_Offload_Fails' FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;

    要查询 secondary_engine_not_used跟踪标记,请发出以下查询:

    SELECT QUERY, TRACE->'$**.secondary_engine_not_used' FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
    笔记

    如果优化器跟踪没有返回所有跟踪信息,请增加优化器跟踪缓冲区大小。有关详细信息,请参阅 运行查询

    对于TIMEDIFF()上面使用的查询示例,查询 Rapid_Offload_Fails标记返回失败的原因:

    mysql> SELECT QUERY, TRACE->'$**.Rapid_Offload_Fails' FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
    +---------------------------------------------------+--------------------------------------+
    | QUERY                                             | TRACE->'$**.Rapid_Offload_Fails'     |
    +---------------------------------------------------+--------------------------------------+
    | EXPLAIN SELECT                                    |[{"Reason": "Function timediff is not |
    | TIMEDIFF(O_ORDERDATE,'2000:01:01 00:00:00.000001')|             yet supported"}]         |
    | FROM ORDERS                                       |                                      |
    +---------------------------------------------------+--------------------------------------+

报告查询卸载失败的原因取决于遇到的问题或限制。对于不支持的子句或功能等常见问题,会报告具体原因。对于优化器执行的未定义问题或不支持的查询转换,报告了以下一般原因:

[{"Reason": "Currently unsupported RAPID query compilation scenario"}]

对于不满足HeatWave的query cost threshold的query,报如下原因:

[{"Reason": "The estimated query cost does not exceed secondary_engine_cost_threshold."}]

查询成本阈值可防止将低成本查询卸载到 HeatWave。有关查询成本阈值的信息,请参阅 第 2.13 节,“故障排除”

对于试图访问定义为 的列的查询, NOT SECONDARY报告了以下原因:

[{"Reason": "Column risk_assessment is marked as NOT SECONDARY."}]

NOT SECONDARY当表加载到 HeatWave 中时, 定义为的列将被排除。请参阅 排除表列

查询运行时和估计

您可以使用 HeatWave Advisor Query Insights 功能或通过查询 performance_schema.rpd_query_stats表 来查看 HeatWave 查询运行时间和运行时间估计。运行时数据对于查询优化、故障排除以及估算运行特定查询或工作负载的成本很有用。

HeatWave 查询运行时数据包括:

  • 成功执行查询的运行时

  • EXPLAIN查询 的运行时估计

  • 使用取消的查询的运行时估计 Ctrl+C

  • 由于内存不足错误而失败的查询的运行时估计

运行时数据可用于 HeatWave 查询历史记录中的查询,它是有关最近 1000 个执行查询的信息的非持久存储。

使用查询洞察

  • 要查看 HeatWave 历史记录中所有查询的运行时数据:

    CALL sys.heatwave_advisor(JSON_OBJECT("query_insights", TRUE));
  • 仅查看当前会话执行的查询的运行时数据:

    CALL sys.heatwave_advisor(JSON_OBJECT("query_insights", TRUE, 
           "query_session_id", JSON_ARRAY(connection_id())));

有关使用Query Insights的其他信息,请参阅 第 2.7.3.3 节,“Query Insights”

使用 rpd_query_stats 表

查看 HeatWave 查询历史中所有查询的运行时数据:

SELECT query_id,
  JSON_EXTRACT(JSON_UNQUOTE(qkrn_text->'$**.sessionId'),'$[0]') AS session_id, 
  JSON_EXTRACT(JSON_UNQUOTE(qkrn_text->'$**.accumulatedRapidCost'),'$[0]') AS time_in_ns, 
  JSON_EXTRACT(JSON_UNQUOTE(qexec_text->'$**.error'),'$[0]') AS error_message
  FROM performance_schema.rpd_query_stats;

要查看特定 HeatWave 查询的运行时数据,按查询 ID 过滤:

SELECT query_id,
  JSON_EXTRACT(JSON_UNQUOTE(qkrn_text->'$**.sessionId'),'$[0]') AS session_id, 
  JSON_EXTRACT(JSON_UNQUOTE(qkrn_text->'$**.accumulatedRapidCost'),'$[0]') AS time_in_ns, 
  JSON_EXTRACT(JSON_UNQUOTE(qexec_text->'$**.error'),'$[0]') AS error_message
  FROM performance_schema.rpd_query_stats WHERE query_id = 1;

EXPLAIN输出包括查询 ID。您还可以在 performance_schema.rpd_query_stats表中查询查询 ID:

SELECT query_id, LEFT(query_text,160) FROM performance_schema.rpd_query_stats;

创建表 ... 选择语句

语句的SELECT查询 CREATE TABLE ... SELECT被卸载到 HeatWave 执行,表在 MySQL 数据库系统上创建。在查询长时间运行且复杂的情况下,将 查询卸载SELECT 到 HeatWave 可以减少 执行时间。由于在 MySQL 数据库系统实例上执行的大量 DML 操作,产生大型结果集的查询无法从该功能中受益。 CREATE TABLE ... SELECTSELECTSELECT

SELECT表必须加载到 HeatWave 中。例如,以下语句从 ordersHeatWave 上的表中选择数据并将结果集插入到orders2MySQL 数据库系统上创建的表中:

mysql> CREATE TABLE orders2 SELECT * FROM orders;

语句的这一SELECT部分 受与常规查询 CREATE TABLE ... SELECT相同的 HeatWave 要求和限制的约束 。SELECT

插入 ... 选择语句

语句的SELECT查询 INSERT ... SELECT被卸载到 HeatWave 执行,结果集被插入到 MySQL 数据库系统上的指定表中。在查询长时间运行且复杂的情况下,将 查询卸载 SELECT到 HeatWave 可以减少 执行时间。由于在 MySQL 数据库系统实例上执行的大量 DML 操作,产生大型结果集的查询无法从该功能中受益。 INSERT ... SELECTSELECTSELECT

SELECT表必须加载到 HeatWave 中,并且该INSERT表必须存在于 MySQL 数据库系统中。例如,以下语句从orderstHeatWave 上的表中选择数据并将结果集插入到orders2 MySQL 数据库系统上的表中:

mysql> INSERT INTO orders2 SELECT * FROM orders;

使用说明:

  • 语句的这一SELECT部分 受与常规查询 INSERT ... SELECT相同的 HeatWave 要求和限制的约束 。SELECT

  • SELECT 查询 中不支持 MySQL 服务器弃用的函数、运算符和属性。

  • ON DUPLICATE KEY UPDATE不支持 该子句。

  • SELECT .. UNION ALLINSERT如果表与表相同,则不会卸载查询,SELECT因为在这种情况下 MySQL 服务器使用临时表,无法卸载。

  • INSERT INTO some_view SELECT语句不会被卸载。在这种情况下,设置 use_secondary_engine=FORCED 不会导致语句因错误而失败。无论设置如何,该语句都在 MySQL 数据库系统上执行 use_secondary_engine

使用视图

HeatWave 支持查询视图。创建视图的表必须加载到 HeatWave 中。对视图执行的查询受与对表执行的查询相同的卸载先决条件和限制的约束。

在以下示例中,在 orders表上创建了一个视图,如 第 2.6 节“表加载和查询示例”中所述。该示例假定订单表已加载到 HeatWave 中。

mysql> CREATE VIEW v1 AS SELECT O_ORDERPRIORITY, O_ORDERDATE FROM orders;

要确定在视图上执行的查询是否可以卸载到 HeatWave 执行,请使用 EXPLAIN. 如果支持卸载,则输出ExtraEXPLAIN显示 Using secondary engine RAPID,如下例所示:

mysql> EXPLAIN SELECT O_ORDERPRIORITY, COUNT(*) AS ORDER_COUNT 
       FROM v1 WHERE O_ORDERDATE >= DATE '1994-03-01' GROUP BY O_ORDERPRIORITY 
       ORDER BY O_ORDERPRIORITY\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: ORDERS
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1488248
     filtered: 33.32999801635742
        Extra: Using where; Using temporary; Using filesort; Using secondary engine RAPID