The general query log records every SQL statement executed on your instance — queries, inserts, updates, and deletes. On a busy instance, this log can grow rapidly and cause storage exhaustion, lock contention, and longer crash recovery times.
ApsaraDB RDS for MySQL stores the general query log inTABLEformat by default. Logs stored inFILEformat cannot be queried or downloaded because you cannot access the instance file system directly. Thelog_outputparameter controls the output format for both the general query log and the slow query log; because RDS uses a rotation mechanism that requiresTABLEformat for slow query logs, the general query log must also useTABLEformat.
Log parameters at a glance
| Parameter | Default | Description |
|---|---|---|
general_log | OFF | Enables or disables the general query log |
log_output | TABLE | Output format. TABLE writes to mysql.general_log; FILE writes to the file system (not supported for download on RDS) |
general_log_size (read-only) | — | Monitoring metric showing the current size of the general query log table |
Why does the general query log consume all my storage space?
On a high-traffic instance, or one where the log hasn't been cleaned in a long time, the general query log grows without bound. To check whether it's the cause, view the storage usage of the instance and look for a large general_log_size value.
To recover storage space, follow the steps in Clean the general query log.
Why do I see many connections in the "Waiting for table level lock" state?
Check by running SHOW PROCESSLIST or querying the innodb_trx table. If many connections show Waiting for table level lock alongside high connection counts and CPU utilization, the general query log is likely the cause.
Because the log is stored as a table, threads write to it serially. Each write acquires a metadata lock (MDL) and a table-level lock. Under high write volume, these locks queue up and block other connections.
Disable the general query log to stop new lock contention, then clean the log table. See Clean the general query log.
Why does my instance take a long time to recover after an unexpected shutdown?
When an instance shuts down unexpectedly, a crash mark is set for the general query log. On the next restart, MySQL triggers an automatic recovery process for the log table. The larger the table, the longer the recovery takes — during which the instance is unavailable, extending your Recovery Time Objective (RTO).
Keeping the general query log disabled during normal operations, and cleaning the log table regularly, keeps the table small and recovery fast.
Clean the general query log
Disable the general query log: set the
general_logparameter toOFF. This stops new log entries from being written. For instructions, see Set instance parameters.Connect to the instance using a privileged account, then run:
TRUNCATE TABLE mysql.general_log;After the command completes, verify the result on the instance monitoring page —
general_log_sizeshould drop to near zero.
TRUNCATE TABLE mysql.general_log is not supported on ApsaraDB RDS for MySQL 5.6 instances. Contact support to clean the log on MySQL 5.6.Best practices
Keep the general query log disabled during normal operations. Enable it only temporarily for debugging or troubleshooting — then clean and disable it immediately after.
For ongoing SQL analysis and auditing, use one of the following alternatives:
(Recommended) SQL Explorer and Audit: Automatically records and analyzes executed SQL statements. Audit data is stored in Database Autonomy Service (DAS) — this does not consume RDS instance storage space or affect instance performance.
Temporary general query log: Enable the general query log temporarily, query the log table, then disable and clean it when done:
SELECT * FROM mysql.general_log;
Next steps
Enable automatic storage expansion — the system expands storage automatically when usage reaches the threshold you configure