如何快速找出MySQL中的大表并进行清理_通过information

查大表体积应以information_schema.tables中data_length+index_length为准，执行sql按大小倒序列出用户表；删表前须确认复制依赖、锁事务及磁盘空间；超50gb表推荐硬链接法：建链→drop→异步rm；删后需清理innodb字典残留和binlog。

如何快速找出mysql中的大表并进行清理_通过information_schema查询

查大表：用 `information_schema.tables` 看真实数据体积

直接看 data_length + index_length 才算准，data_free 是碎片，不是“可用空间”。别被 SHOW TABLE STATUS 的模糊值误导。

执行这句就能按大小倒序列出所有用户表：

SELECT table_schema, table_name, 
       ROUND((data_length + index_length) / 1024 / 1024 / 1024, 2) AS size_gb,
       table_rows 
FROM information_schema.tables 
WHERE table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
  AND (data_length + index_length) > 1024 * 1024 * 1024  -- 大于1GB才显示
ORDER BY (data_length + index_length) DESC;

table_rows 是估算值，InnoDB 下不准，不能用来判断是否该删；只信 size_gb
如果某张表 size_gb 很大但 table_rows 很小，大概率是碎片严重，不是真有那么多数据
注意 table_schema 别漏过滤，否则会把系统库的 innodb_table_stats 这类元数据表也列进来

删大表前必须确认的三件事

别急着 DROP TABLE，先验证这三项，否则可能秒删表但磁盘不释放、主从延迟爆表、或误删正在被应用读写的影子表。

确认表是否在主从复制链路中被依赖：SHOW CREATE TABLE 看有没有触发器或外键引用；查 SELECT * FROM performance_schema.replication_applier_status_by_coordinator 确保没被并行复制任务盯上
检查是否有长事务或未提交的 SELECT ... FOR UPDATE 正锁着这张表：SELECT * FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id IN (SELECT id FROM information_schema.PROCESSLIST WHERE info LIKE '%table_name%')
确认磁盘剩余空间是否 ≥ 表大小的 1.5 倍：MySQL 删除大表时，buffer pool 清理和 ibdata1（如果是共享表空间）收缩都可能临时写入日志或临时页

真正“快速”删除大表的硬链接法

当表文件本身超 50GB，DROP TABLE 仍要卡住十几秒甚至更久（尤其 buffer pool 污页多时），这时得绕过 MySQL 文件管理，靠 Linux 硬链接腾挪。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

步骤本质是：先建硬链接 → DROP TABLE → 后台异步删链接文件。

先定位表文件路径：SELECT @@datadir;，再进对应库目录找 xxx.ibd 和 xxx.frm（MySQL 8.0+ 是 xxx.sdi）
建硬链接（必须在同一文件系统！）：ln /var/lib/mysql/dbname/xxx.ibd /tmp/xxx.ibd.hdlk
执行 DROP TABLE xxx; —— 这步立刻返回，因为只是删了原 inode 引用
等业务低峰期再删硬链接：rm /tmp/xxx.ibd.hdlk，此时才真正释放磁盘空间

注意：ls -l 看第二个字段数字，从 2 变成 1 才代表只剩一个引用，rm 才安全。别在 DROP 后立刻 rm，否则可能丢数据。

删完表还要盯住两处残留

表删了不等于万事大吉。这两处常被忽略，会导致后续导入同名表失败、或者磁盘空间迟迟不涨。

InnoDB 字典里残留：如果 DROP 中断过（比如 kill -9 mysqld），INFORMATION_SCHEMA.INNODB_SYS_TABLES 可能还存着记录，需重启 mysqld 或手动清理（高危，不建议）
binlog 里没 purge：大表 DROP 会产生巨大 binlog 事件，如果 expire_logs_days 设得太大，这些日志会占满磁盘。删表后立刻执行：PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 1 HOUR);

硬链接法虽快，但 rm 那一下仍是同步 IO 峰值操作——务必避开业务高峰，且提前用 iostat -x 1 看好磁盘 await 值。