mysql 8.0迁移期audit_log插件无法可靠审计敏感操作，因其不记录sql内容、database策略无效、不覆盖存储过程/复制/动态sql等场景；必须改用mariadb的server_audit插件，并配合触发器与row格式binlog交叉验证。
audit_log 插件在 MySQL 8.0 迁移期间无法可靠追踪敏感操作——它记录的是事件元数据，不是 SQL 内容；且 audit_log_policy=DATABASE 在社区版中根本无效，日志里不会带库名、表名或字段上下文。
audit_log 插件在迁移期的实际能力边界
迁移期间最关心的“谁在哪个库改了哪张表”这类问题，audit_log 原生不支持：
- audit_log_format 设为 JSON 后，能拿到 sql_text 字段，但仅限 QUERY 类型事件（即客户端直接发的语句）；存储过程、事件调度器、复制线程、PREPARE/EXECUTE 动态 SQL 都不记录
- audit_log_policy=DATABASE 是摆设：插件在 SQL 解析前就写日志，无法提取 USE db_name 或 db.table 前缀，日志里没有 database 字段
- command_class 字段只对 GRANT/REVOKE/CREATE USER 等权限类操作有效，对 INSERT/UPDATE/DELETE 不出现
- 迁移常伴随批量脚本、mysqldump --single-transaction、pt-online-schema-change 等工具调用，这些操作多数不会触发 QUERY 事件，或被归为 SYSTEM 类型而被 audit_log_policy 过滤掉
server_audit 插件才是迁移期可用的审计方案
必须换用 MariaDB 的 server_audit 插件（兼容 MySQL 8.0.22+），并严格配置才能捕获真实 SQL：
- 下载与你 MySQL 架构（x86_64 或 aarch64）、主版本（如 8.0.33）、编译器（GCC 版本）完全匹配的 server_audit.so，否则加载失败或崩溃
- server_audit_events 必须显式包含 query（不是 all，后者会漏掉语法错误语句）
- server_audit_output_type=file，路径设为 /var/log/mysql/server_audit.log，避免写进表导致迁移时锁表或日志丢失
- 启动后立即验证：执行 SELECT 1;，再 tail -n 1 /var/log/mysql/server_audit.log，应看到类似 QUERY 12345 root@localhost SELECT 1 的行，不含库名前缀则说明应用未规范使用 db.table 格式
迁移期敏感操作必须靠触发器补位
仅靠日志插件会漏掉三类关键操作：
- 应用层隐式 USE 后执行的语句（如先 USE finance 再 UPDATE users，日志里无 finance 字符串）
- 存储过程中循环更新多张表的逻辑（server_audit 只记 CALL 语句，不记内部 DML）
- 跨库操作（如 UPDATE accounting.users JOIN payroll.salary ON ...），日志里只保留原始 SQL，无法自动标注涉及哪些库
- 正确做法是在目标敏感表上建 BEFORE UPDATE 和 BEFORE DELETE 触发器，写入自定义审计表：
• 用 IF DATABASE() = 'finance' 做库级守门，防跨库误触
• 记录 USER()、NOW()、CONNECTION_ID()、OLD.*/NEW.* 快照
• 对大字段做 IF LENGTH(OLD.ssn) > 0 THEN ... 条件写入，避免日志爆炸
别忽略 binlog 的交叉验证价值
迁移期间 binlog 是唯一能还原“实际删了哪几行”的证据源，但必须提前配好：
- binlog_format = ROW（不可妥协）
- binlog_row_image = FULL（否则旧值缺失）
- binlog_rows_query_log_events = ON（否则看不到原始语句和用户）
- 迁移开始前执行 FLUSH LOGS，确保新 binlog 文件从干净状态起始
- 若已发生误操作，用 mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 10 "DELETE_ROWS_EVENT" 定位位置，再向上翻查紧邻的 QUERY_EVENT 行，里面含 user@host 和完整 SQL —— 这是定位操作人最后的可信依据
迁移审计不是开个插件就完事。真正起作用的是 server_audit 日志 + 触发器快照 + binlog 三者交叉比对；任何单一来源都可能因配置偏差、工具行为或 MySQL 内部机制而漏记。
