How to use the SQL Explorer and Audit feature of PolarDB for MySQL - PolarDB

SQL Explorer and Audit captures all SQL activity on your PolarDB for MySQL cluster, powered by Database Autonomy Service (DAS). Use it to diagnose query performance, audit SQL operations, detect security threats, and replay traffic for capacity planning.

Task	Feature	Description
Find and export specific SQL statements	Search (Audit)	Query SQL logs by database, status, execution time, or client IP address. Learn more
Analyze query performance	SQL Explorer	View execution duration distributions, identify slow queries, and compare performance across time ranges. Learn more
Review SQL workload patterns	SQL Review	Analyze SQL payload across your cluster. Get index optimization and SQL rewrite suggestions. Learn more
Detect security threats	Security Audit	Flag high-risk operations, SQL injection attempts, and new access sources. Learn more
Validate scaling decisions	Traffic Playback and Stress Testing	Replay production traffic against your cluster to test whether current specifications handle peak loads. Learn more
Analyze transaction behavior	Transaction Analysis	Inspect transaction types, counts, and details for a specific thread within a time range. Learn more
Trace a transaction lifecycle	Quick Transaction Analysis	Find the start and end statements of a transaction containing a specific SQL statement. Determine whether it was committed or rolled back. Learn more
Correlate SQL with metric changes	Related SQL Identification	Identify SQL statements whose execution trends most closely match changes in a selected metric.

Supported regions

SQL Explorer and Audit requires DAS Enterprise Edition. Supported regions vary by Enterprise Edition version. For details, see Databases and regions supported by each edition.

Performance impact

Enabling or disabling SQL Explorer and Audit does not require a cluster restart.

SQL Explorer and Audit records all DQL, DML, and DDL statements. DAS collects this information directly from database kernels with minimal overhead:

Resource	Impact
CPU and memory	Negligible
Network	None
Disk	None -- audit data is stored by DAS, not on cluster disks
Storage	Uses DAS-provided storage, not your cluster's storage space

Prerequisites

Before you begin, ensure that you have:

A PolarDB for MySQL cluster
DAS Enterprise Edition enabled for your Alibaba Cloud account
(RAM users only) The AliyunPolardbReadOnlyWithSQLLogArchiveAccess permission to use the Search (Audit) feature. See Create and manage RAM users

A custom policy can also grant access to the Search feature, including the export function. See Use a custom policy to authorize a RAM user to use the Search feature of SQL Explorer and Audit.

Billing

Enterprise Edition V0

SQL Explorer is billed on a pay-as-you-go basis only. Subscription billing and resource plans are not supported. Fees are billed as part of the PolarDB service.

Region	Price
Chinese mainland	USD 0.0013/GB/hour
Hong Kong (China) and regions outside China	USD 0.0019/GB/hour

Enterprise Edition V1 and later

Fees are billed as part of DAS. For pricing details, see Product billing of Database Autonomy Service (DAS).

Enable SQL Explorer and Audit

Log on to the PolarDB console. In the navigation pane, click Clusters. Select the region of your cluster, then click the cluster ID.
In the navigation pane, choose Logs and Auditing > SQL Explorer.
Click Enable SQL Explorer.

If DAS Enterprise Edition is not enabled for your Alibaba Cloud account, follow the on-screen instructions to enable it.

After enabling, the following tabs are available:

Search (Audit) -- Query and export SQL statements by database, status, execution time, and other criteria.
SQL Explorer -- Analyze query performance using the views described in the following section.

After you enable SQL Explorer, wait about 30 minutes before audit logs become available in the Search (Audit) tab.

SQL Explorer views

Display by Time Range

Select a time range to view Execution Duration Distribution, Execution Duration, and Executions for all SQL statements. The Full Request Statistics section lists individual SQL templates with their execution duration percentage, average duration, and execution trend.

Up to 1,000 SQL logs can be exported from this view. For larger exports, use Search (Audit).

Display by Comparison

Select two time points to compare SQL performance side by side. The Requests by Comparison section shows detailed differences.

Source Statistics

View the origin of SQL statements within a selected time range, broken down by access source.

SQL Review

Analyze cluster workload for a selected time range against a baseline. Generates index optimization suggestions, SQL rewrite suggestions, Top SQL, New SQL, Failed SQL, SQL feature analysis, SQL with execution plan changes, SQL with performance degradation, and top traffic tables.

Related SQL Identification

Select a metric and click Analysis. After 1 to 5 minutes, the system identifies SQL statements whose execution trends most closely match the metric's change pattern.

Traffic Playback and Stress Testing

Replay captured traffic to determine whether cluster specifications can handle upcoming business peaks or schema changes, such as index modifications.

Security Audit

Detect threats including high-risk operations, SQL injection attempts, and new access sources.

Transaction Analysis

Analyze transaction details for a selected thread and time range. Available with DAS Enterprise Edition V3 hot storage data. Generates trend charts for different transaction types.

Key metrics

Execution Duration Distribution

Shows how SQL query execution times are distributed across seven ranges:

Range	Description
[0, 1] ms	Execution time from 0 to 1 ms
(1, 2] ms	Greater than 1 ms, up to 2 ms
(2, 3] ms	Greater than 2 ms, up to 3 ms
(3, 10] ms	Greater than 3 ms, up to 10 ms
(10, 100] ms	Greater than 10 ms, up to 100 ms
(0.1, 1] s	Greater than 100 ms, up to 1 s
> 1 s	Greater than 1 s

The chart uses color coding to indicate query health: blue areas represent healthy execution times, while orange and red areas indicate slower queries that may need optimization.

Execution Duration

Displays the execution duration trend for all SQL queries within the selected time range.

Full Request Statistics

Lists SQL templates with:

SQL text -- The normalized SQL pattern
Execution duration percentage -- Calculated as: (template execution duration x execution count) / (total duration x total executions) x 100%. A higher percentage means more database resources are consumed by that template
Average execution duration
Execution trend

Click an SQL ID to view the performance trend and sample data for that SQL template. The SQL Sample tab shows the client that initiated each request.

SQL samples are encoded in UTF-8.

Modify storage duration

Warning

Reducing the storage duration immediately deletes audit logs beyond the new retention period. Export logs before making changes.

Log on to the PolarDB console. In the navigation pane, click Clusters. Select the region of your cluster, then click the cluster ID.
In the navigation pane, choose Logs and Auditing > SQL Explorer.
In the upper-right corner, click Service Settings.
Adjust the storage duration and click OK.

With DAS Enterprise Edition V3, storage durations can be configured separately for each sub-feature. Audit data is stored by DAS and does not consume your cluster's storage space.

Disable SQL Explorer and Audit

Warning

Disabling SQL Explorer and Audit permanently deletes all audit logs. Export logs before disabling. After re-enabling, recording starts from the re-enable time.

Log on to the PolarDB console. In the navigation pane, click Clusters. Select the region of your cluster, then click the cluster ID.
In the navigation pane, choose Logs and Auditing > SQL Explorer.
Click Service Settings to disable SQL Explorer and Audit.
Click OK.

If audit log collection was enabled through CloudLens for PolarDB in Simple Log Service, disable that collection separately. See Enable data ingestion.

Export SQL records before disabling. See Export SQL log records.

With DAS Enterprise Edition V3, you can review and selectively disable individual sub-features.

View audit log size and costs

Log on to the Alibaba Cloud Management Console. In the upper-right corner, choose Expenses.
In the left-side navigation pane under Expenses and Costs, choose Bill Management > Billing Details.
On the Billing Details tab, click Details, then filter by Instance ID. Look for entries where Billing Item is sql_explorer.

Migrate to the new version

Migration is supported only for clusters in China (Hangzhou), China (Shanghai), China (Beijing), and China (Shenzhen).

Log on to the PolarDB console. In the navigation pane, click Clusters. Select the region of your cluster, then click the cluster ID.
In the navigation pane, choose Logs and Auditing > SQL Explorer.
In the Upgrade SQL Explorer to "SQL Explorer and Audit" dialog box, click One-click Upgrade.

Migrate between Enterprise Edition versions

Enterprise Edition V2 introduced hybrid hot and cold storage to reduce costs. Enterprise Edition V3 builds on this architecture with feature-based billing for further savings.

If your cluster supports Enterprise Edition V3, migrate from V1 or V2 for lower costs. See How do I migrate data between different DAS Enterprise Edition versions?

FAQ

Can I use a resource plan to offset SQL Explorer costs?

No. SQL Explorer supports only pay-as-you-go billing. Subscription billing and resource plans are not available.

What is the `logout!` statement in Full Request Statistics?

logout! indicates a disconnected connection. Its duration represents the time between the last interaction and the disconnect event -- essentially the connection's idle time. A status code of 1158 means the network connection was dropped. Common causes:

Client connection timeout
Abnormal server-side disconnection
Server reset due to exceeding interactive_timeout or wait_timeout

Why does `%` appear as an access source in Source Statistics?

This typically happens when using stored procedures. If a procedure's DEFINER uses the % wildcard in the host portion (for example, CREATE DEFINER='test_user'@'%' PROCEDURE ...), the source appears as % in the statistics.

Why does the database name in the audit log differ from the one in the SQL statement?

The log records the database name from the active session, while the SQL statement may reference a different database explicitly -- for example, in cross-database queries or dynamic SQL. The two values are independent.

Does enabling SQL Explorer and Audit affect database performance?

The impact is minimal. CPU and memory consumption is negligible. Audit data is stored by DAS, so there is no impact on network performance, disk I/O, or cluster storage.

An `UPDATE` statement shows 1 affected row, but the data did not change. How do I troubleshoot this?

In the audit log, find the SQL statement and note the Thread ID.
Click Enable Advanced Search and filter by that Thread ID.
Check whether AUTOCOMMIT is disabled for the thread. If it is, look for an explicit COMMIT after the UPDATE.

Filter by Thread ID first. Add other conditions only if too many results are returned.

Common causes:

AUTOCOMMIT disabled without COMMIT -- The UPDATE executed but was never committed, so the change was not persisted.
Transaction ROLLBACK -- A rollback after the UPDATE reverted all changes in the transaction. Look for a ROLLBACK statement after the UPDATE in the thread's log.

If neither applies, consider recovering the database and table and parsing the binlog to confirm whether the modification was actually recorded.