不能直接删除这两个文件！直接删除会导致 MySQL 服务异常崩溃、数据损坏甚至无法启动，需根据文件类型采用 安全的清理方式，具体操作如下：
一、先明确两个文件的作用（为何不能直接删）
文件名称 作用说明 直接删除风险
ibtmp1 InnoDB 的临时表空间文件，存储临时表数据（如查询中的GROUP BY/ORDER BY生成的临时表） 直接删除会导致 MySQL 立即崩溃，数据可能损坏
mysql-bin.00023 MySQL 的二进制日志文件（binlog），记录数据库的所有写操作（用于主从同步、数据恢复） 直接删除可能破坏主从同步，或导致无法恢复历史数据
二、安全清理方案（按文件类型操作）
1. 清理 ibtmp1 文件（InnoDB 临时表空间）
ibtmp1 会随着临时表的创建而增大，但默认情况下 不会自动缩小，需通过重启 MySQL 并配置参数限制其大小：
步骤 1：修改 MySQL 配置文件（限制 ibtmp1 大小）
在 [mysqld] 段添加 / 修改以下参数，避免后续再次无限增大：
ini
[mysqld]
# 其他配置不变，新增两行
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:512M # 限制最大512M（可根据需求调整）
innodb_purge_threads = 4 # 加速临时表空间回收（可选，优化性能）
12M：初始大小；max:512M：限制最大尺寸，超过后会报错（需确保业务临时表不会超此大小）。
步骤 2：重启 MySQL 服务（自动重建 ibtmp1）
ibtmp1 只能通过 重启 MySQL 清理（重启后会自动删除旧文件并生成新的空文件）：
bash
# 停止MySQL服务（根据你的系统环境选择命令）
systemctl stop mysqld # CentOS/RHEL 7+
# 或
service mysql stop # Ubuntu/Debian
# 启动MySQL服务
systemctl start mysqld
# 或
service mysql start
重启后检查 data 目录，ibtmp1 会变成初始大小（如 12M），旧的大文件已被自动清理。
2. 清理 mysql-bin.00023 二进制日志文件（binlog）
二进制日志的清理需遵循 “按保留时间 / 文件数量自动清理” 原则，避免破坏主从同步或数据恢复能力：
前提检查：确认日志是否已过期 / 无用
先查看当前正在使用的 binlog 文件，避免删除正在使用的日志（正在使用的日志无法删除）：
bash
# 登录MySQL命令行
mysql -u root -p
# 查看当前正在写入的binlog文件（结果如：mysql-bin.00025）
show master status;
如果 mysql-bin.00023 小于当前正在使用的文件编号（如当前是 00025），说明它是历史日志，可安全清理；
如果当前正在使用的就是 00023，说明业务依赖该日志（如主从同步），不能删除，需先确认主从同步完成后再处理。
步骤 1：通过 MySQL 命令自动清理（推荐，安全无风险）
使用 PURGE BINARY LOGS 命令清理，支持按 时间 或 文件编号 清理：
sql
-- 方式1：清理“指定日期之前”的所有binlog（如清理3天前的，与配置的expire_logs_days一致）
PURGE BINARY LOGS BEFORE DATE_SUB(CURDATE(), INTERVAL 3 DAY);
-- 方式2：清理“指定文件之前”的所有binlog（如清理mysql-bin.00023及之前的日志）
-- 注意：需确保mysql-bin.00023不是当前正在使用的日志（参考前提检查）
PURGE BINARY LOGS TO 'mysql-bin.00024'; # 清理到00024之前（即删除00023及更早的）
步骤 2：配置自动清理（避免后续手动操作）
如果之前已配置 expire_logs_days = 3（保留 3 天日志），MySQL 会 自动删除超过 3 天的历史 binlog，无需手动清理；
若未配置，可在 [mysqld] 段确认 / 添加：
ini
[mysqld]
expire_logs_days = 3 # 保留3天日志（根据业务恢复需求调整，如1-7天）
max_binlog_size = 100M # 限制单个binlog最大100M（避免单个文件过大）
配置后，MySQL 会在后台自动清理过期日志，无需手动干预。
三、后续预防：避免文件再次过大
定期重启 MySQL：建议每周 / 每月重启一次（非业务高峰），可自动回收 ibtmp1 临时空间（若未配置 max 限制）；
监控 binlog 保留时间：根据业务需求设置 expire_logs_days（如主从同步场景保留 1 天即可，单机场景可缩短到半天）；
避免大临时表：优化 SQL 查询（如减少不必要的 GROUP BY/ORDER BY，避免生成超大临时表），降低 ibtmp1 增长速度。
四、注意事项
操作前 备份关键数据：若数据库重要，建议先通过 mysqldump 备份核心表，避免意外；
主从同步场景需谨慎：清理 binlog 前，需确认从库已完全同步该日志（可通过 show slave status 查看 Relay_Master_Log_File 是否小于待清理的 binlog 编号）；
避免频繁重启：若业务不允许重启，可先通过 kill 长期运行的临时表查询（show processlist 查看 State 为 Creating tmp table 的进程，谨慎 kill ID），临时缓解 ibtmp1 增长。
