Slow query log

更新时间:
复制 MD 格式

Slow queries can severely impact database stability. When you encounter high workloads or performance fluctuations, start by checking for slow queries. Database Autonomy Service (DAS) provides a slow query log analysis feature that tracks and analyzes requests that exceed a specified time threshold. This helps you quickly identify and resolve database performance issues and improve system stability and reliability.

Prerequisites

  • The database engine is one of the following:

    • Tair (Redis-compatible)

    • MyBase Redis

  • Your target database instance must be connected to DAS with a Normal Connection status. For more information, see Connect an Alibaba Cloud database instance to DAS.

Background information

Slow query log statistics help you view detailed information about slow queries on your instance. You can easily find the most frequently executed slow queries, the ones with the longest execution times, and those that scan the most rows on average.

Slow query logs are generated by the database kernel. The configuration parameters and thresholds vary depending on the database engine. For specific details, see the official documentation for your database engine.

Procedure

  1. Log on to the DAS console.

  2. In the navigation pane on the left, click Intelligent O&M Center > Instance Monitoring .

  3. Find the target instance and click the instance ID to open the instance details page.

  4. In the left-side navigation pane, click Request Analysis > Slow log.

  5. On the slow query log details page, select a time range to view the Slow Query Log Trends, Event Distribution, and Slow Query Log Details for that period.

    • You can click a point on the Slow Query Log Trends chart to view the Slow Query Log Details for that specific time.

      Note

      For instances using cluster or read/write splitting architectures, you can view slow query log details for Data Node and Proxy Node, as well as the Slow Request Count for each node.

    • Click the image icon to save the slow query log information to your computer.

    • Click the image icon to go to OpenAPI Explorer with the current parameters pre-filled for API debugging.

    • In the Event Distribution section, you can query slow query log events within the specified time range. Click an event to view its details.

    • In the Slow Query Log Details section, details for all slow queries are displayed by default, including Execution Completion Time, Database, Slow Query Statement, Execution Duration (ms), and Host Address. You can click Settings to filter the results.

      Note

      For instances using cluster architecture or read/write splitting, the Host Address defaults to the proxy IP address. To obtain the client IP address, perform one of the following operations:

      • For performance-enhanced Tair instances with local disks: In Parameter Settings, set the ptod_enabled parameter to 1. For more information, see Set parameters.

      • For open source Redis instances: Enable audit logs, and then view the client IP address for the specific event in the audit log of the proxy node.

Special slow query statements

Note

These queries are related to the instance's internal kernel logic and are not directly tied to the execution speed of your actual requests. You can safely ignore the following slow query statements.

  • latency:eventloop

    Tair (Redis-compatible) uses an event-driven model at runtime. A single event loop includes reading, parsing, and executing a command, and then returning the result. The execution duration of a latency:eventloop statement represents the total time taken for one event loop.

  • latency:pipeline

    Tair (Redis-compatible) supports client-side pipeline mode. In this mode, the client sends a batch of commands and receives a batch of results after all commands are executed. By default, the proxy server of a Tair cluster instance uses pipeline mode to send requests to the backend Redis. The execution duration of a latency:pipeline statement represents the total time taken to execute all requests from a single client in a pipeline batch.

  • latency:fork

    The execution duration of a latency:fork statement represents the time spent creating a child process by using fork. The larger the amount of data, the longer the fork process takes.

FAQ