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%';

+------------+-----------------+------+------------+-----------+-----------+----------------+--------+

+------------+-----------------+------+------------+-----------+-----------+----------------+--------+-

| 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%';

+------------+-----------------+------+------------+-----------+-----------+----------------+--------+

+------------+-----------------+------+------------+-----------+-----------+----------------+--------+-

| 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）审计日志

默认不开启。第三方则有，增长比较大。控制其大小。

posted @ 2024-08-30 00:40 cdrcsy 阅读(0) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

MySQL空间优化（空间清理）

公告