本文列舉開啟general log的常見問題供您參考。
背景信息
基于以下原因，RDS MySQL選擇TABLE作為general log的默認存儲格式：
保存為FILE格式用戶無法進行查詢，因為用戶無法直接訪問RDS MySQL的文件。
general log和slow log同時受log_output參數影響，RDS MySQL在采集slow log時使用了rotate的機制，需要保存為TABLE格式。
General log占據大量存儲空間
問題描述
RDS MySQL實例存儲空間已滿，通過如下排查，確認為general log文件過大導致。
查看實例存儲空間使用量，sys_data_size文件過大。詳情請參見查看監控信息。
查看實例參數，實例已開啟general_log（運行參數值為ON）。詳情請參見查看實例參數。
連接RDS MySQL實例并執行如下語句，查詢發現general log文件過大。連接實例的詳細請參見連接RDS MySQL實例。
SELECT table_schema AS '數據庫', table_name,SUM(data_length + index_length + data_free)/1024/1024 AS "表大小MB",SUM(DATA_FREE)/1024/1024 AS "碎片大小MB" FROM information_schema.TABLES WHERE table_name='general_log'說明此SQL語句會從
information_schema數據庫的TABLES表中檢索mysql.general_log表的數據，然后將其轉換成以MB為單位的大小。此SQL語句獲得的數據為抽樣數據，和實際數據存在一定誤差。
問題原因
當RDS MySQL開啟了general log后，該文件記錄了用戶的所有操作，包括每條SQL語句的執行細節，無論是查詢、插入、更新還是刪除操作。當訪問量大或者長時間不清理general log文件時，會占用大量的存儲空間，導致存儲空間耗盡。
General log導致性能問題
問題描述
連接數上升，CPU使用率升高。通過SHOW PROCESSLIST或者查看innodb_trx表等方式，可見大量連接處于Waiting for table level lock狀態。
問題原因
RDS MySQL選擇TABLE作為general log的默認存儲格式，各線程寫general log是串行寫入的。這是因為寫general log除了需要加MDL鎖以外，還需要加表鎖。也正是該表鎖導致了“Waiting for table level lock”狀態的出現。
General log導致RTO變長
問題描述
實例崩潰恢復時間變長，在此期間實例處于無法連接狀態。
問題原因
實例非正常Shutdown ，general log的Crash標記位會置為true，導致實例重啟后進入到自動恢復的邏輯，當表很大時，恢復時間很長，此過程中實例無法連接。
解決方法
清理general log文件
關閉general log（運行參數值設為OFF），以防止產生新的日志。詳情請參見設置實例參數。
使用高權限賬號連接RDS MySQL實例并執行如下語句，清理general log文件。連接實例的詳細信息請參見連接RDS MySQL實例。
說明RDS MySQL 5.6版本實例不支持通過TRUNCATE命令清理general log文件。
TRUNCATE TABLE mysql.general_log;
后續維護
建議只在調試或跟蹤問題時臨時開啟general log，使用完成之后請及時關閉general log。
建議您開啟SQL洞察和審計，該功能可以自動記錄和分析來自數據庫內核的SQL語句，以及SQL語句的執行賬號、IP地址、執行詳情等信息，對實例性能沒有影響。并且SQL洞察和審計數據存儲在數據庫自治服務DAS中，不占用RDS MySQL存儲空間。
擴容實例存儲空間，詳情請參見變更配置。您也可以開啟存儲空間自動擴容，在實例存儲空間達到設定的閾值時，系統會自動擴容存儲空間，詳情請參見設置存儲空間自動擴容。