gtid_executed 表不可truncate或delete，因其是mysql 8.0+只读系统表，存储已执行gtid压缩快照，删之将致主从不一致；应通过purge binary logs自动更新该表。
gtid_executed 表为什么不能直接 TRUNCATE 或 DELETE？
因为 gtid_executed 是 MySQL 8.0+ 的系统表（mysql.gtid_executed），InnoDB 引擎下它是只读的，任何 TRUNCATE、DELETE 或 DROP 都会报错：ERROR 1582 (42000): Incorrect parameter count in the call to native function 'GTID_SUBSET' 或更直白的 ERROR 1290 (HY000): The MySQL server is running with the --gtid-executed-compression-ratio option so it cannot execute this statement。它不是普通业务表，而是 GTID 持久化的关键元数据，MySQL 自己维护。
实操建议：
- 不要尝试绕过权限或引擎限制去写它——哪怕加
SET SQL_LOG_BIN = 0也无效 - 它的内容本质是「已执行 GTID 集合的压缩快照」，不是日志流水，删了会导致主从 GTID 不一致、复制中断
- 真正该清理的是二进制日志（
binlog），gtid_executed表会随PURGE BINARY LOGS自动合并更新
purge binary logs 到底清什么？和 gtid_executed 什么关系？
PURGE BINARY LOGS 清的是磁盘上的 binlog 文件，但会触发 MySQL 重算并刷新 mysql.gtid_executed 表：把已 purge 的 binlog 中的 GTID 合并进当前快照，压缩存储。所以这不是“删除 GTID”，而是“把已归档的 GTID 归并到一个紧凑集合里”。
常见错误现象：
- 手动删了
binlog文件但没用PURGE命令 →gtid_executed不更新，后续SHOW MASTER STATUS仍显示旧范围，空间也没真释放 - 设了
expire_logs_days = 1但发现gtid_executed表行数还在涨 → 因为 binlog 还没被自动 purge（需等 flush + rotate 触发），或从库还没拉完
实操建议：
- 优先用
PURGE BINARY LOGS TO 'mysql-bin.000123'或PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00'，别依赖定时任务脚本 rm 文件 -
gtid_executed表单行记录可存上万个 GTID（靠压缩算法），所以即使 binlog 很多，它通常也就几行 —— 行数暴涨往往意味着压缩失效，检查是否开了gtid_executed_compression_period = 0
gtid_executed_compression_period 设成 0 有多危险？
这个变量控制 MySQL 多久主动合并一次 gtid_executed 表里的 GTID 区间。默认是 1000（单位：事务数），设成 0 就等于“永不压缩”。后果是：每条 INSERT、UPDATE 只要生成新 GTID，就往表里追加一行区间记录，表迅速膨胀到几万行，严重拖慢 SHOW SLAVE STATUS、SELECT @@gtid_executed 等操作，甚至导致从库 IO 线程卡住。
使用场景：
- 仅在极早期调试 GTID 合并逻辑时临时设为 0，生产环境必须保持非零值
- 如果已经设成 0 且表已膨胀，不能直接删数据；只能先设回合理值（如 1000），再强制触发一次 binlog rotate：
FLUSH BINARY LOGS，让 MySQL 在下次 purge 时重新压缩
性能影响：
- 压缩周期越小（如 100），写放大越高，但表体积可控；越大（如 10000），单次压缩耗时略长，但日常查询更快
- MySQL 8.0.23+ 改进了压缩算法，
gtid_executed_compression_period = 1000是平衡点，不建议调低
自动 purge 频率怎么配才不翻车？
靠 expire_logs_days 控制自动清理，但它只在每次 binlog rotate 时检查，不是实时定时器。也就是说：如果写入量低、binlog 很少切换，可能一周都不 purge 一次，gtid_executed 表也不更新。
容易踩的坑：
- 设了
expire_logs_days = 1但磁盘还是满 → 因为当前binlog文件还没写满，没触发 rotate，自然不检查过期 - 主库 purge 了，但从库
Retrieved_Gtid_Set还卡在旧位置 → 从库 IO 线程断连或网络延迟，导致它没来得及拉取就被 purge，复制直接失败
实操建议：
- 用
max_binlog_size（如 128M）配合expire_logs_days，确保活跃度低的实例也能定期 rotate - 监控从库的
Seconds_Behind_Master和Retrieved_Gtid_Set，确保它比主库Executed_Gtid_Set至少超前 2 个 binlog 文件再 purge - 定期跑
SELECT @@global.gtid_executed;对比主从，如果从库返回空或明显缺失，说明 purge 已越界，得马上停操作、重搭复制
最常被忽略的一点：GTID purge 不是独立动作，它绑在 binlog 生命周期里。想管好 gtid_executed，本质是管好 binlog 的生成、传输、落盘、清理全链路 —— 单独盯着那个表本身，永远理不清。
