本文列舉開啟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儲存空間。
擴容執行個體儲存空間，詳情請參見變更配置。您也可以開啟儲存空間自動擴容，在執行個體儲存空間達到設定的閾值時，系統會自動擴容儲存空間，詳情請參見設定儲存空間自動擴容。