MySQL空间优化(空间清理)
当数据库磁盘空间不足的时候,一般选择扩容,归档,优化表空间。
优化表空间主要包括:重复索引、未使用的索引,表空间大小情况,清理碎片。
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)审计日志
默认不开启。第三方则有,增长比较大。控制其大小。