最直白的证据链起点是检查 general_log 是否开启，若开启且级别足够，可直接从日志中看到谁、何时、用哪个账号执行了 TRUNCATE TABLE；否则需结合 binlog（ROW 格式+GTID 或 user_var）、performance_schema、系统审计日志及中间件日志交叉验证。
查 general_log 是否开启并包含操作记录
TRUNCATE 本身不记入 slow log，但若 general_log 开启且级别足够（即记录所有语句），就可能直接看到谁、何时、用哪个账号执行了 TRUNCATE TABLE。这是最直白的证据链起点。
先确认是否启用：SHOW VARIABLES LIKE 'general_log'; 和 SHOW VARIABLES LIKE 'general_log_file';。如果值为 OFF，这条路立即中断——MySQL 默认关闭该日志，且开启后对性能有明显影响，生产库极少长期开启。
若已开启，用文本工具搜索日志文件：grep -B2 -A2 "TRUNCATE TABLE `your_table`" /var/lib/mysql/general.log。注意匹配完整表名和反引号，避免误命中其他语句。输出中会包含时间戳、连接ID、用户@主机、执行线程ID，这些是定位责任人的原始依据。
从 binlog 提取执行者信息（需 ROW 格式 + GTID 或 user_var）
mysqlbinlog 解析出的 binlog 内容默认不带用户名，但有两个例外路径可间接推断：
- 如果启用了
binlog_rows_query_log_events=ON（MySQL 5.6.2+），mysqlbinlog -v输出中会出现# INSERT INTO ...上方带注释的原始 SQL，其中可能含SET @user = 'xxx'类似上下文（取决于应用是否显式设 session 变量） - 若使用 GTID 且开启了
log_replica_updates=ON（主从场景），从库 binlog 中的@@SESSION.GTID_NEXT可关联到主库事务，再结合主库performance_schema.events_statements_history（需提前开启 consumers）回溯
更现实的做法是：用 mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A5 -B5 "TRUNCATE" 定位事件位置，然后检查该 binlog 文件生成时段内，哪些账号在 performance_schema.threads 中活跃过——前提是 performance_schema 已启用且历史未被轮转清空。
检查 MySQL 错误日志与系统审计日志交叉验证
MySQL 自身错误日志（mysqld.log）一般不记 DML/DDL，但某些异常场景下会留下线索：比如 TRUNCATE 触发磁盘空间不足告警、权限拒绝记录（Access denied for user 'xxx'@'yyy'）、或因锁等待超时产生的堆栈。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
真正关键的是操作系统层审计。Linux 系统若配置了 auditd，可通过以下命令查是否有 mysqld 进程被特定用户调用：aureport -m -ts recent --key mysql 或 ausearch -m execve -i -ts 2026-11-04 20:00:00 -te 2026-11-04 23:00:00 | grep -i truncate。这需要 DBA 提前部署审计规则，否则无从追溯。
另一个常被忽略的点：数据库连接池或中间件（如 ProxySQL、ShardingSphere）通常自带操作审计，日志里会明确记录客户端 IP、应用名、发起用户、SQL 原文。翻查这些组件的日志比死磕 MySQL 原生日志更高效。
为什么无法 100% 确定责任人？
TRUNCATE 是 DDL，MySQL 不在事务中记录执行者字段；binlog 默认不存用户名；general_log 多数生产环境关闭；performance_schema 历史数据易被覆盖。最终能锁定责任人，往往依赖外部日志（审计系统、中间件、堡垒机）而非 MySQL 自身能力。
最容易被忽略的细节是：即使你拿到某条 TRUNCATE 的 binlog 事件，也无法区分它是应用自动触发、DBA 手动执行，还是某个定时脚本通过 cron 调用 mysql 客户端执行的——三者在 MySQL 层面留下的痕迹完全一致。真正有效的追溯，必须从接入层开始埋点。
