All Products
Search

This Product

    ApsaraDB RDS:SQL Explorer and Audit

    Document Center

    ApsaraDB RDS:SQL Explorer and Audit

    Last Updated:May 09, 2026

    For security compliance audits, performance analysis, and troubleshooting, enable SQL Explorer and Audit. This feature automatically records all SQL statements executed in the database kernel and their related information, such as the executing account, IP address, and execution details. It has a negligible impact on instance performance and provides reliable data for querying historical SQL records and performing subsequent analysis and auditing.

    Prerequisites

    Important

    The SQL Explorer and Audit feature records all Data Query Language (DQL), Data Manipulation Language (DML), and Data Definition Language (DDL) operations. This information is output by the database kernel and consumes minimal CPU resources.

    Feature overview

    SQL Explorer and Audit provides features such as Search (audit), SQL Explorer, security audit, traffic playback and stress testing, and SQL analysis.

    • Search (audit): Query and export the execution history of SQL statements and their related information, such as the database, status, and execution time.

    • SQL Explorer: Diagnose the health of SQL statements, troubleshoot performance issues, and analyze business traffic within a specified time range.

    • Security audit (legacy): Automatically identifies risks such as high-risk SQL statements, SQL injection, and new access sources.

    • Traffic playback and stress testing: Provides traffic playback and stress testing features to help you verify whether your instance specifications need to be scaled up to handle peak business traffic.

    • SQL analysis: Analyzes SQL statements over a specified period to identify abnormal SQL statements and locate performance issues.

    SQL Explorer and Audit is commonly used in the following scenarios:

    • Industries with strict data security requirements, such as finance, security, securities, government, and insurance.

    • Scenarios that require detailed investigation of database operations, such as issue troubleshooting, SQL statement performance investigation, and abnormal session investigation.

    • In cases of data loss or damage, use the SQL statements recorded by SQL Explorer to analyze issues and aid data recovery.

    Supported regions

    China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Hong Kong), Singapore, Japan (Tokyo), Malaysia (Kuala Lumpur), Indonesia (Jakarta), US (Silicon Valley), UK (London), US (Virginia), and Germany (Frankfurt)

    Billing details

    • If you purchased an instance and enabled the SQL Explorer feature before it was upgraded to SQL Explorer and Audit: The feature fee is charged by RDS on an hourly basis. Prices vary based on the instance region.

      • USD 0.0015 per GB/hour: China (Hong Kong), US (Silicon Valley), and US (Virginia).

      • USD 0.0018 per GB/hour: Singapore, Japan (Tokyo), Germany (Frankfurt), UAE (Dubai), Malaysia (Kuala Lumpur), Indonesia (Jakarta), and UK (London).

      • USD 0.0012 per GB/hour: China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), and China (Chengdu).

      Note

      You can click One-click Upgrade in the upgrade dialog box that appears on the SQL Explorer tab to upgrade to SQL Explorer and Audit. After the upgrade, the fee is charged by DAS.

    • If you enable the SQL Explorer and Audit feature after the upgrade: The fee is charged by DAS. You can use the SQL Explorer and Audit feature only after you enable Database Autonomy Service (DAS) Enterprise Edition. The supported regions and billing methods vary based on the edition. For more information, see Databases and regions supported by each DAS Enterprise Edition and Product billing of each DAS Enterprise Edition.

      Note

      In the console, you can enable only the latest version of DAS Enterprise Edition that is supported in the current region.

    Usage notes

    • Online query:

      • Time range: A single online query can span a maximum of 24 hours. You can query data for any 24-hour period within the data retention period. Queries that span the maximum duration may time out. If you need to query SQL records over a longer time range, use Simple Log Service (SLS) to access the audit logs. For more information, see Collect audit logs of an ApsaraDB RDS for MySQL instance.

      • Query method: Online queries support combined searches but not fuzzy searches. Keywords must be at least four characters long.

    • SQL Explorer and Audit:

      • Maximum SQL statement length: The maximum length of an SQL statement that can be recorded is 8192 bytes. This length is also affected by the loose_rds_audit_max_sql_size parameter (for MySQL 5.6/5.7) or the loose_rds_audit_log_event_buffer_size parameter (for MySQL 8.0). The effective limit is the minimum of these values. Due to a prefix added during data collection and processing, the actual recorded length of an SQL statement is slightly less than 8,192 bytes or the value of the parameter.

      • Audit record query: You can query SQL statement records by thread ID and transaction ID. To query records by transaction ID, you must set the loose_rds_audit_log_version parameter to MYSQL_V3. Specific minor engine versions are required: the minor engine version of MySQL 8.0 must be 20210930 or later, and the minor engine version of MySQL 5.7 must be 20210630 or later. For more information, see Parameters of an ApsaraDB RDS for MySQL 8.0 instance and Update the minor engine version of an ApsaraDB RDS for MySQL instance.

      • SQL Explorer (Trial Edition): If you are using the trial edition of SQL Explorer, you cannot call the DescribeSQLLogRecords and DescribeSQLLogFiles API operations to query audit logs.

      • Lock wait time: The audit logs contain the lock wait time, whereas the slow query log does not.

      • When an application uses the prepare method, two statements appear in SQL Explorer: one with a question mark and the other with a specific value.

    • If you connect to an instance by using the endpoint of a database proxy and the transaction-level connection pool is enabled for the proxy, connections may be reused. In this case, the IP address and port shown by the show processlist command or in SQL Explorer may be different from the actual client IP address and port.

    • When an SQL statement is executed on an ApsaraDB RDS for MySQL instance that is attached to a PolarDB-X 1.0 instance, multiple logs are generated in SQL Explorer and Audit on the ApsaraDB RDS for MySQL instance due to horizontal sharding.

    • Log integrity: In the following extreme scenarios, some SQL Explorer and Audit logs may be lost:

      • The instance is under high load and has performance bottlenecks.

      • The instance receives a high volume of SQL requests.

      • The audit log collection service is not running correctly.

    Enable SQL Explorer and Audit

    Note

    • If you enable the audit log collection feature for your ApsaraDB RDS for MySQL instance in CloudLens for RDS of Simple Log Service (SLS), the SQL Explorer and Audit feature is automatically enabled for the instance.

    • If you have not enabled the SQL Explorer and Audit feature, you can view the binary log. The binary log allows you to query only the SQL statements for data additions, deletions, and modifications that are generated within the backup retention period. You cannot view the source IP address or account information.

    1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

    2. In the left-side navigation pane, choose Autonomy Services > SQL Explorer and Audit.

    3. Click Enable DAS Enterprise Edition V3.

    4. Select the features that you want to enable and click Activate.

    Modify data storage duration

    Warning

    When you reduce the data retention period for SQL Explorer and Audit, DAS immediately deletes any SQL audit logs older than the new period. Before reducing the retention period, export and save your logs.

    1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

    2. In the left-side navigation pane, choose Autonomy Services > SQL Explorer and Audit.

    3. Click Service Settings.

    4. On the Service Settings page, modify the log storage duration for Audit Scenarios and click Submit.

    Disable SQL Explorer and Audit

    Warning

    After you disable SQL Explorer and Audit, DAS clears all existing logs. Export and save the logs before disabling the feature. When you re-enable the feature, logs are recorded from the time of re-enabling.

    1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

    2. In the left-side navigation pane, choose Autonomy Services > SQL Explorer and Audit.

    3. On the Audit tab, in the Logs section, click Export.

    4. In the dialog box that appears, select the fields and time range to export, and then click OK.

      Note

      • You can export a maximum of 10 million records from a seven-day period in a single task.

      • You can set the Export Time Range to export SQL records for a longer period.

    5. After the export is complete, download the exported file and save it securely.

    6. Click Service Settings to disable SQL Explorer and Audit.

      If you have enabled DAS Enterprise Edition V3, clear the check boxes for all features of SQL Explorer and Audit, and click Submit.

      Note

      About one hour after you disable the SQL Explorer and Audit feature, the system releases the storage space used for its data.

    Migrate data between Enterprise Editions

    Warning

    The migration operation cannot be terminated or rolled back. Read the migration instructions carefully before you proceed.

    If your database instance supports Enterprise Edition V3, you can migrate data from Database Autonomy Service (DAS) Enterprise Edition V1 or V2 to Enterprise Edition V3 to benefit from more favorable pricing. For more information, see How do I migrate data between different versions of DAS Enterprise Edition?

    Compared with Enterprise Edition V1, Enterprise Edition V2 uses a different underlying storage architecture that achieves cost-effectiveness through hybrid storage of hot and cold data. Enterprise Edition V3 is built on this hybrid storage architecture and provides more flexible billing by itemizing charges based on the features used.

    FAQ

    Q: ️SQL Explorerlogout! statement in the Full Request Statistics section of SQL Explorer mean?

    A: logout! indicates a disconnection. The duration of a logout! event is the difference between the time of the last interaction and the time the logout! event occurred. This duration represents the connection idle time. A status of 1158 in the Status column indicates a network disconnection, which can be caused by the following reasons:

    • The client connection timed out.

    • The server was disconnected unexpectedly.

    • The server connection was reset because it exceeded the interactive_timeout or wait_timeout period.

    Q: ️SQL Explorer%) appear as the Access Source in Source Statistics within SQL Explorer?

    A: This can occur when you use a stored procedure. The following example shows how to reproduce this scenario:

    Note

    In this example, the database instance is ApsaraDB RDS for MySQL, the test account is test_user, and the test database is testdb.

    1. Create a standard-privilege account and a database in the ApsaraDB RDS console, and then grant the account permissions on the database. For more information, see (Deprecated, redirected to "Step 1") Create databases and accounts.

    2. Use the test account to connect to the database instance from the command-line interface (CLI). For more information, see (Deprecated, redirected to "Step 2") Connect to an ApsaraDB RDS for MySQL instance by using a client or the CLI.

    3. Switch to the test database and create the following stored procedure.

      -- Switch to the test database.
USE testdb;

-- Create a stored procedure.
DELIMITER $$
DROP PROCEDURE IF EXISTS `das` $$
CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
BEGIN
SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
END $$
DELIMITER;

    4. Use a privileged account to connect to the database instance. For more information, see (Deprecated, redirected to "Step 2") Connect to an ApsaraDB RDS for MySQL instance by using a client or the CLI.

    5. Call the stored procedure.

      -- Switch to the test database.
USE testdb;

-- Call the stored procedure.
CALL das();

+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

    Q: In the log list of the audit feature for an ApsaraDB RDS for MySQL instance, why is the number of scanned rows 0 for some SQL statements that return data?

    A: The query_cache_type parameter is enabled for the database instance. In the log list, the scanned row count for an SQL statement is the number of rows scanned in the InnoDB engine layer. When query_cache_type is enabled, MySQL caches the query results. If a subsequent, identical query request is received and the query cache is hit, MySQL returns the cached result directly without querying the InnoDB layer. This is why data is returned, but the scanned row count in the log list is 0. For more information, see Fast Query Cache.

    Q: What are the differences between SQL Explorer and the binary log?

    You can view incremental data of an ApsaraDB RDS for MySQL instance by using SQL Explorer or the binary log. The following list describes the differences:

    • SQL Explorer: This feature is suitable for obtaining all incremental data in a database. However, when the instance is under high load, a small number of records may be lost. As a result, statistics on incremental data collected by using this feature may be inaccurate. This feature can record all DQL, DML, and DDL operations. This information is output by the database kernel and consumes minimal CPU resources.

    • Binary log: This feature is suitable for obtaining accurate incremental data in the short term but cannot obtain real-time log information. This feature accurately records all data addition, deletion, and modification operations in the database and is used to restore incremental data for users. Binary log files are temporarily stored in the instance. The system periodically transfers completed binary log files from the instance to Object Storage Service (OSS) for 7 days of retention. Binary log files that are currently being written to cannot be uploaded. Therefore, after you click Upload Binlog, some binary log files are not uploaded. For more information, see Remotely obtain and parse the binary log of an ApsaraDB RDS for MySQL instance.

    Q: Why has the entry point for SQL Explorer disappeared from the instance console?

    A: Due to a feature version update, the entry point for the latest version has been changed to SQL Explorer and Audit.

    Q: Can I still enable an earlier version of SQL Explorer?

    A: No. You can enable only the latest version of SQL Explorer and Audit supported by this instance.

    Q: Are the original records retained after I export SQL records?

    A: Yes. The export operation does not delete the original audit records.