當資料庫磁碟空間不足的時候，一般選擇擴容，歸檔，最佳化表空間。
最佳化表空間主要包括：重複索引、未使用的索引，表空間大小情況，清理碎片。
undo redo 臨時表空間 binlog relaylog general_log error_log 等。
還有一種，MySQL資料庫崩潰，執行失敗，執行超時，異常情況下可能會導致一些存放中間結果的殘留的中間表。
一般以#sql開頭。
以下清理方法，均可能導致大量的buffer io的佔用，因此在業務低峰期執行，避免影響業務，甚至MySQL崩潰。
一、索引表空間
(1) 索引
查詢沒有主鍵的表
SELECT * FROM information_schema.tables AS t
LEFT JOIN (SELECT DISTINCT table_schema, table_name FROM information_schema.`KEY_COLUMN_USAGE` ) AS kt ON kt.table_schema=t.table_schema AND kt.table_name = t.table_name
WHERE t.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema')
and t.table_type='BASE TABLE'
AND kt.table_name IS NULL
重複索引和未使用索引
show create table xxxx；去分析
或者 查詢重複索引 和未使用過的索引
select * from sys.schema_redundant_indexes;
select * from sys.schema_unused_indexes;
如果沒有開啟。或者SQL：
select a.`table_schema`,a.`table_name`,a.`index_name`,a.`index_columns`,b.`index_name`,b.`index_columns`,concat('ALTER TABLE `',a.`table_schema`,'`.`',a.`table_name`,'` DROP INDEX `',a.`index_name`,'`') from ((select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`) a
join (select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`) b
on(((a.`table_schema` = b.`table_schema`) and (a.`table_name` = b.`table_name`))))
where ((a.`index_name` <> b.`index_name`) and (((a.`index_columns` = b.`index_columns`) and ((a.`non_unique` > b.`non_unique`) or ((a.`non_unique` = b.`non_unique`) and (if((a.`index_name` = 'PRIMARY'),'',a.`index_name`) > if((b.`index_name` = 'PRIMARY'),'',b.`index_name`))))) or ((locate(concat(a.`index_columns`,','),b.`index_columns`) = 1) and (a.`non_unique` = 1)) or ((locate(concat(b.`index_columns`,','),a.`index_columns`) = 1) and (b.`non_unique` = 0))));
未使用過的索引：
select `information_schema`.`statistics`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`statistics`.`TABLE_NAME` AS `table_name`,`information_schema`.`statistics`.`INDEX_NAME` AS `index_name`,max(`information_schema`.`statistics`.`NON_UNIQUE`) AS `non_unique`,max(if(isnull(`information_schema`.`statistics`.`SUB_PART`),0,1)) AS `subpart_exists`,group_concat(`information_schema`.`statistics`.`COLUMN_NAME` order by `information_schema`.`statistics`.`SEQ_IN_INDEX` ASC separator ',') AS `index_columns` from `information_schema`.`statistics` where ((`information_schema`.`statistics`.`INDEX_TYPE` = 'BTREE') and (`information_schema`.`statistics`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','PERFORMANCE_SCHEMA'))) group by `information_schema`.`statistics`.`TABLE_SCHEMA`,`information_schema`.`statistics`.`TABLE_NAME`,`information_schema`.`statistics`.`INDEX_NAME`
查詢索引的使用情況
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted from schema_index_statistics where table_schema='dbname';
清理方法：完成後空間會立刻釋放
alter table tab_name drop index idx_name;
drop index idx_name on tab_name;
(2)表空間大小（篩選大表)：
SELECT table_schema AS 'Database', ROUND (SUM (data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)' FROM information_schema.tables GROUP BY table_schema
檢視看物理檔案大小：
5.7及以上
SELECT
CONCAT(SUM(TOTAL_EXTENTS), ' MB') AS TotalFileSize
FROM
INFORMATION_SCHEMA.FILES;
#5.7以下
SELECT table_schema AS '資料庫', table_name,SUM(data_length + index_length + data_free)/1024/1024 AS "表大小M"
FROM information_schema.tables
WHERE table_schema ='資料庫名'
GROUP BY table_schema,table_name ;
表碎片率
SELECT CONCAT(table_schema,'.',table_name) AS 'table_name',
table_rows AS 'table_rows',
CONCAT(ROUND(data_length/(1024*1024),2),' M') AS data_size,
CONCAT(ROUND(index_length/(1024*1024),2),' M') AS index_size ,
CONCAT(ROUND((data_length + index_length)/( 1024 * 1024 ), 2), 'M') AS total_size,
CONCAT(ROUND(data_free/(1024*1024),2),' M') AS'data_free',
CONCAT(ROUND(data_free/(data_length + index_length + data_free),2),' %') AS 'data_free_pct',
ENGINE as 'engine'
FROM information_schema.TABLES
WHERE ROUND(DATA_FREE/1024/1024,2) >=5
ORDER by data_free desc;
或者指定碎片率大於50%的表：
where (data_free / (data_length + index_length + data_free)) * 100 >50;
清理方法：回收碎片空間，包括表和索引，立刻釋放
optimize table tab_name;
ALTER TABLE xxxx ENGINE= INNODB
部分資料資料歸檔，使用delete語句是無法釋放空間，只會標記資料行。需要使用optimize table來回收空間。
不需要的表庫/已經歸檔的表庫。(可以使用mysqldump直接匯出SQL語句，歸檔至本地)
drop table tab_name/drop database db_name
如果還是無法回收空間。可以新建表,遷移資料到新表的方法回收。
lock table tab_name;
insert into new_tab_name select * from tab_name;
rename tab_name to old_tab_name; rename new_tab_name to tab_name;
drop table old_tab_name;
(6) undo 表空間
mysql undo 表空間設定自動擴充套件，如果業務上有跑批次或者大表的DML操作時，引起大事物，或針對多張大表關聯更新時間較長，大量的未提交長事務等。可能短時間內會導致undo表空間暴漲。
MySQL8.0方法：
mysql8.0 innodb_undo_log_truncate引數預設開啟的，並且mysql8.0中預設innodb_undo_tablespace為2個。
mysql> show variables like '%undo%';
+--------------------------+-----------------------+
| Variable_name | Value |
+--------------------------+-----------------------+
| innodb_max_undo_log_size | 4294967296 |
| innodb_undo_directory | /data1/mysql8/undolog |
| innodb_undo_log_encrypt | OFF |
| innodb_undo_log_truncate | ON |
| innodb_undo_tablespaces | 2 |
+--------------------------+-----------------------+
5 rows in set (0.01 sec)
mysql> system du -sh /data/mysql8/undolog/*
16M /data/mysql8/undolog/undo_001
16M /data/mysql8/undolog/undo_002
新增新的undo表空間undo003。系統預設是2個undo，大小設定4G
mysql>create undo tablespace undo003 add datafile '/data/mysql8/undolog/undo003.ibu';
注意：建立新增新的undo必須以.ibu結尾，否則觸發錯誤.
檢視系統中的undo表空間資訊，如下：
mysql>select * from information_schema.INNODB_TABLESPACES where name like '%undo%';
+------------+-----------------+------+------------+-----------+-----------+----------------+--------+
| SPACE | NAME | FLAG | ROW_FORMAT | PAGE_SIZE | FILE_SIZE | ALLOCATED_SIZE | STATE |
+------------+-----------------+------+------------+-----------+-----------+----------------+--------+-
| 4294967279 | innodb_undo_001 | 0 | Undo | 16384 | 16777216 | 16777216 | active|
| 4294967278 | innodb_undo_002 | 0 | Undo | 16384 | 16777216 | 16777216 | active|
| 4294967277 | undo003 | 0 | Undo | 16384 | 16777216 | 16777216 | active|
+------------+----------------------+----+------------+-----------+---------------+------------+---------+
3 rows in set (0.00 sec)
檢視到上述檢視中 innodb_undo_002 大小達到16777216 （16M）其狀態state為active。手動將其設定為 inactive，使其自動觸發 innodb_undo_log_truncate 回收。
mysql >alter undo tablespace innodb_undo_002 set inactive;
mysql >select * from information_schema.INNODB_TABLESPACES where name like '%undo%';
+------------+-----------------+------+------------+-----------+-----------+----------------+--------+
| SPACE | NAME | FLAG | ROW_FORMAT | PAGE_SIZE | FILE_SIZE | ALLOCATED_SIZE | STATE |
+------------+-----------------+------+------------+-----------+-----------+----------------+--------+-
| 4294967279 | innodb_undo_001 | 0 | Undo | 16384 | 16777216 | 16777216 | active|
| 4294967278 | innodb_undo_002 | 0 | Undo | 16384 | 16777216 | 16777216 | empty |
| 4294967277 | undo003 | 0 | Undo | 16384 | 16777216 | 16777216 | active|
+------------+-----------------+------+------------+-----------+---------------+------------+---------+
3 rows in set (0.00 sec)
此時可以檢視對應作業系統目錄中的 undo_002狀態 empty
檢視新增的undo003檔案大小
mysql >system du -sh /data1/mysql8/undolog/*
16M /data1/mysql8/undolog/undo_001
1M /data1/mysql8/undolog/undo_002
16M /data1/mysql8/undolog/undo003.ibu
重新將innodb_undo_002設定為active狀態
mysql >alter undo tablespace innodb_undo_002 set active;
確認狀態。
mysql >select * from information_schema.INNODB_TABLESPACES where name like '%undo%';
為什麼直接不能直接針對膨脹的undo設定為inactive，系統預設建立的undo表空間預設2個，不得少於2個。
新建立新增的可以正常設定為inactive之後，使用drop方式刪除，如下：
mysql >alter undo tablespace undo003 set inactive;
mysql >drop undo tablespace undo003;
mysql>system du -sh /data1/mysql8/undolog/*
總結：
1、增加undo表空間的數量大於2.
2、設定膨脹的undo表空間為inactive
3、系統引數innodb_undo_log_truncate開啟後會自動回收。innodb_purge_rseg_truncate_frequency調小可加快回收
4、設定原undo表空間為active，刪除新新增的表空間。
MySQL 5.5方法：
MySQL5.5以及之前，InnoDB的undo log也是存放在ibdata1裡面的。一旦出現大事務，這個大事務所使用的undo log佔用的空間就會一直在ibdata1裡面存在，即使這個事務已經關閉。
沒有直接的辦法，只能全庫匯出sql檔案，然後重新初始化mysql例項，再全庫匯入
MySQL 5.6方法：
MySQL 5.6增加了引數：獨立表空間，從ibdata1中獨立出來。
innodb_undo_directory undo表空間目錄，例項初始化之後不可更改
innodb_undo_logs回滾段的個數，預設128。
innodb_undo_tablespaces，表空間個數。 例項初始化之後不可更改。
沒有直接的辦法，只能全庫匯出sql檔案，然後重新初始化mysql例項，再全庫匯入
MySQL 5.7方法：
MySQL 5.7引入了新的引數，innodb_undo_log_truncate，開啟後可線上收縮拆分出來的undo表空間。
在滿足以下2個條件下，undo表空間檔案可線上收縮：
（1）innodb_undo_tablespaces>=2。因為truncate undo表空間時，該檔案處於inactive狀態，如果只有1個undo表空間，那麼整個系統在此過程中將處於不可用狀態。為了儘可能降低truncate對系統的影響，建議將該引數最少設定為3；
（2）innodb_undo_logs>=35（預設128）。因為在MySQL 5.7中，第一個undo log永遠在系統表空間中，另外32個undo log分配給了臨時表空間，即ibtmp1，至少還有2個undo log才能保證2個undo表空間中每個裡面至少有1個undo log；
滿足以上2個條件後，把innodb_undo_log_truncate設定為ON即可開啟undo表空間的自動truncate，這還跟如下2個引數有關：
（1）innodb_max_undo_log_size，undo表空間檔案超過此值即標記為可收縮，預設1G，可線上修改；
（2）innodb_purge_rseg_truncate_frequency,指定purge操作被喚起多少次之後才釋放rollback segments。當undo表空間裡面的rollback segments被釋放時，undo表空間才會被truncate。由此可見，該引數越小，undo表空間被嘗試truncate的頻率越高。
# 為了實驗方便，我們減小該值
innodb_max_undo_log_size = 100M
innodb_undo_log_truncate = ON
innodb_undo_logs = 128
innodb_undo_tablespaces = 3
innodb_purge_rseg_truncate_frequency = 10
create table t1(
id int primary key auto_increment,
name varchar(200));
insert into t1(name) values(repeat('a',200));
......
插入足夠多的資料。 這時undo表空間檔案大小如下，可以看到有一個undo檔案已經超過了100M：
-rw-r----- 1 mysql mysql 13M Feb 17 17:59 undo001
-rw-r----- 1 mysql mysql 128M Feb 17 17:59 undo002
-rw-r----- 1 mysql mysql 64M Feb 17 17:59 undo003
此時，為了，讓purge執行緒執行，可以執行幾個delete語句：
mysql> delete from t1 limit 1;
......
再檢視undo檔案大小：
-rw-r----- 1 mysql mysql 13M Feb 17 18:05 undo001
-rw-r----- 1 mysql mysql 10M Feb 17 18:05 undo002
-rw-r----- 1 mysql mysql 64M Feb 17 18:05 undo003
可以看到，超過100M的undo檔案已經收縮到10M了。
(7) redo 表空間
MySQL8.0 方法
從MySQL8.0.30開始支援引數innodb_redo_log_capacity。該引數設定redo日誌的總大小，預設100MB，最大值為128G。該引數設定後原有的innodb_log_files_in_group和innodb_log_file_size引數將被忽略。
MySQL會自動在innodb_log_group_home_dir目錄中建立#innodb_redo，每個檔案大小為innodb_redo_log_capacity/32。測試環境中設定總大小320M，每一個redo檔案大小10M。 未使用的redo日誌檔名帶_tmp字尾。
mysql> select @@global.innodb_redo_log_capacity;
+-----------------------------------+
| @@global.innodb_redo_log_capacity |
+-----------------------------------+
| 335544320 |
+-----------------------------------+
1 row in set (0.00 sec)
mysql> system ls -lthr /data/mysql/log/#innodb_redo
total 320M
-rw-r----- 1 mysql mysql 10M Oct 19 15:58 #ib_redo2_tmp
-rw-r----- 1 mysql mysql 10M Oct 19 15:58 #ib_redo3_tmp
-rw-r----- 1 mysql mysql 10M Oct 19 15:58 #ib_redo4_tmp
-rw-r---- 1 mysql mysql 10M Oct 19 15:58 #ib_redo5_tmp
-rw-r----- 1 mysql mysql 10M Oct 19 15:58 #ib_redo1
-rw-r-----. 1 mysql mysql 10M Oct 19 15:58 #ib_redo6_tmp
.....
當前使用的redo日誌:
mysql> select * from performance_schema.innodb_redo_log_files\G
*************************** 1. row ***************************
FILE_ID: 1
FILE_NAME: /data/mysql/log/#innodb_redo/#ib_redo1
START_LSN: 101996544
END_LSN: 112480256
SIZE_IN_BYTES: 10485760
IS_FULL: 0
CONSUMER_LEVEL: 0
1 row in set (0.00 sec)
redo日誌寫入的當前LSN:
mysql> show global status like 'Innodb_redo_log_current_lsn';
+-----------------------------+-----------+
| Variable_name | Value |
+-----------------------------+-----------+
| Innodb_redo_log_current_lsn | 102001409 |
+-----------------------------+-----------+
1 row in set (0.00 sec)
也可以用LSN的變化量預估一個合理的redo檔案大小
#可以使用以下SQL評估1分鐘lsn的變化量，作為innodb_redo_log_capacity的值。
mysql> select @a:=(select VARIABLE_VALUE from global_status where VARIABLE_NAME='Innodb_redo_log_current_lsn');select sleep(60);select @b:=(select VARIABLE_VALUE from global_status where VARIABLE_NAME='Innodb_redo_log_current_lsn');select (@b-@a)/1024/1024;
+--------------------------------------------------------------------------------------------------+
| @a:=(select VARIABLE_VALUE from global_status where VARIABLE_NAME='Innodb_redo_log_current_lsn') |
+--------------------------------------------------------------------------------------------------+
| 102016920 |
+--------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
+-----------+
| sleep(60) |
+-----------+
| 0 |
+-----------+
1 row in set (1 min 0.00 sec)
+--------------------------------------------------------------------------------------------------+
| @b:=(select VARIABLE_VALUE from global_status where VARIABLE_NAME='Innodb_redo_log_current_lsn') |
+--------------------------------------------------------------------------------------------------+
| 102037622 |
+--------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
+----------------------+
| (@b-@a)/1024/1024 |
+----------------------+
| 0.019742965698242188 |
+----------------------+
1 row in set (0.01 sec)
沒有辦法回收。重新初始化例項，匯入資料。
(8) 臨時表
MySQL在以下幾種情況會建立臨時表：
1、UNION查詢（MySQL 5.7起，執行UNION ALL不再產生臨時表，除非需要額外排序。）；
2、用到TEMPTABLE演算法或者是UNION查詢中的檢視；
3、ORDER BY和GROUP BY的子句不一樣時；
4、表連線中，ORDER BY的列不是驅動表中的；
5、DISTINCT查詢並且加上ORDER BY時；
6、SQL中用到SQL_SMALL_RESULT修飾符的查詢；
7、FROM中的子查詢（派生表）；
8、子查詢或者semi-join時建立的表；
9、評估多表UPDATE語句；
10、評價GROUP_CONCAT()或COUNT(DISTINCT) 表示式計算；
要確定語句是否需要臨時表，請使用EXPLAIN並檢查Extra列以檢視是否顯示Using temporary。但對於派生或實物化的臨時表EXPLAIN不一定會顯示Using temporary。
MySQL內部引數tmp_table_size表示內部的臨時表的最大值，其實生效的是tmp_table_size和max_heap_table_size這兩個值之間的最小的那個值。當建立的臨時表超過這個值(或者max_heap_table_size)時，MySQL將會在磁碟上建立臨時表。
當伺服器建立內部臨時表（在記憶體或磁碟上）時，會增加Created_tmp_tables狀態變數（SHOW PROCESSLIST可以看到）。如果伺服器在磁碟上建立表（最初或透過轉換記憶體中的表），它會增加Created_tmp_disk_tables狀態變數。
mysql> show global status like '%Created_tmp%';
透過檢查Created_tmp_disk_tables和Created_tmp_tables這兩個global狀態值來判斷在磁碟上建立臨時表的次數來進行相應的調優。
某些查詢條件阻止使用記憶體中臨時表，在以下幾種情況下，會建立磁碟臨時表：
1、表中存在BLOB或TEXT列；
2、在SELECT列表中存在任何字串列的最大長度大於512（二進位制字串的位元組），如果被UNION或UNION ALL使用；
3、SHOW COLUMNS FROM DB和DESCRIBE語句中使用BLOB作為用於某些列的型別；
default_tmp_storage_engine是控制CREATE TEMPORARY TABLE建立的臨時表的引擎型別，在以前預設是MEMORY。
內部臨時表 可以在記憶體中保持並且由MEMORY儲存引擎處理，或者由儲存在磁碟上的InnoDB或MyISAM儲存引擎處理。
從MySQL 5.7.5開始，新增一個系統選項internal_tmp_disk_storage_engine可定義磁碟臨時表的引擎型別為InnoDB
show global variables like '%internal_tmp_disk_storage_engine%';
5.7開始
innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:30G 超過上限時，需要生成臨時表的SQL無法被執行.
檢查INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO，找到最大的臨時表對應的執行緒，kill之即可釋放,但表空間並不會釋放。
ibtmp1重啟時會被重新初始化，因此釋放方法：重啟例項。
(9) binlog
設定自動刪除10天之前的binlog：
mysql> set global expire_logs_days = 10;
手動刪除。刪除mysql-bin.000002之前的binlog日誌(不包括mysql-bin.000002)
mysql> PURGE MASTER LOGS TO 'mysql-bin.000002';
刪除指定時間之前的
mysql> PURGE MASTER LOGS BEFORE '2020-06-19 00:00:00';
刪除多少天前的。
PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY);
注意：清理之前，檢視當前master的位點。slave同步的位點。避免主從複製異常。
reset master
方法可以刪除列於索引檔案中的所有二進位制日誌，把二進位制日誌索引檔案重新設定為空，並建立一個以.000001為字尾新的二進位制日誌檔案。 該語法一般只用在主從環境下初次建立複製時。 在主從複製進行過程中，該語句是無效的。
(10) relay log
relay log通常不需要人工清理，因為從庫的複製執行緒在應用完relay log中的事務後，會自動把relay log刪除。每次複製的IO執行緒重啟，都會生成一個新的relay log，每個relay log檔案的大小由引數max_relay_log_size控制，該引數預設為0，即表示其大小和binlog檔案大小一致，通常也為1G。
清理方法：
執行命令來清除relay log檔案，比如：reset slave 和 reset slave all。這兩個命令會忘記主從複製關係的位置資訊，master.info檔案和relay-log.info，將relay log檔案全部刪除，並且生成新的索引從1開始的relay log。使用之前必須使用stop slave 命令將複製程序停止。
mysql>STOP SLAVE;
mysql>reset slave
mysql>STOP SLAVE;
注 所有的relay log將被刪除不管他們是否被SQL thread程序完全應用。
在 5.6 版本中 reset slave 並不會清理儲存於記憶體中的複製資訊，在5.6.3 版本以及以後 使用使用 RESET SLAVE ALL 來完全的清理複製連線引數資訊。
(11) general_log 和 慢查詢日誌slow_log
有三個引數：general_log、log_output、general_log_file，
set global general_log=on; -- 開啟日誌功能
set global general_log_file='tmp/general.log'; -- 設定日誌檔案儲存位置
set global log_output='table'; -- 設定輸出型別為 table。則資料會直接儲存在mysql.general_log中。
set global log_output='file'; -- 設定輸出型別為file，這會儲存在general_log_file指定的位置
清理方法：
SET GLOBAL general_log = 'OFF';
truncate table mysql.general_log;
如果是輸出到檔案。者直接清空。
echo > tmp/general.log
慢日誌
set global slow_query_log = on;
set global slow_query_log_file = '/data/slow.log';
set global long_query_time = 3;
log_output 同上，指定輸出的型別。表還是檔案。
清理方法：
SET GLOBAL slow_query_log = 'OFF';
truncate table mysql.slow_log;
如果是輸出到檔案。直接清空。
echo > /data/slow.log
(12) error_log
一般輸出到檔案。記錄執行日誌，啟動關閉，死鎖，錯誤，異常等資訊。
配置[mysqld]中
log_error = /data/error.log
log_error_verbosity=2 #錯誤日誌級別，記錄的資訊不同。
清理方法：
echo > /data/error.log
（13）殘留的中間表。
SELECT * FROM information_schema.innodb_sys_tables WHERE name like '%#sql%';
或者系統下，資料目錄下的表檔案。
非常多類似#sql-*.ibd暫時檔案和同檔名稱的#sql-*.frm
清理方法：
drop table `#mysql50##sql-928_76f7`;
（14）審計日誌
預設不開啟。第三方則有，增長比較大。控制其大小。