通用日志必须开在主库，因从库只读无法启用；但主库日志不记录真实客户端ip和用户名，需结合应用层连接属性、row格式binlog及审计插件，并统一utc时间戳实现精准溯源。
主从环境里通用日志不能直接开在从库上
从库默认是只读的，SET GLOBAL general_log = ON 会报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。通用日志必须开在主库，否则根本收不到写操作记录。但主库日志里没有客户端 IP 和真实用户名（只显示 user@host，而 host 往往是中间代理或从库自身）。所以单靠主库通用日志，无法定位到原始发起请求的应用服务器或 DBA 终端。
二进制日志必须设为 ROW 格式并保留足够时长
binlog_format = STATEMENT 只存 SQL 文本，看不出哪一行被改了；binlog_format = ROW 才能拿到变更前后的完整行数据，配合 mysqlbinlog --base64-output=DECODE-ROWS -v 解析出 @1=123 @2="old" 这类字段级快照。但注意：server_id 必须全局唯一，否则从库同步时会跳过事件；expire_logs_days 建议设为至少 7 天——审计时经常要回溯“上周三下午三点谁删了订单表”，日志过期就彻底没辙。
审计插件只能装在主库，且需额外补全缺失元数据
MySQL Enterprise Audit 或 MariaDB Audit Plugin 都不支持在从库加载（会拒绝启动）。装在主库后，audit_log_policy = ALL 能捕获 GRANT、UPDATE 等动作，但日志里没有 client_ip 字段——它只记录 user 和 host（后者常是负载均衡器地址）。要真正锁定变更源，得做两件事：
• 在应用层连接池配置中显式传入 user=app_prod;password=xxx;connection_attributes=app_name,ip=10.20.30.40，这样 USER() 和 CONNECTION_ID() 才能关联到真实终端
• 把审计日志接入 SIEM 工具（如 ELK），用 Grok 规则从 query 字段提取 IP（例如匹配 /* ip=10.20.30.40 */ UPDATE ...）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
触发器方案在主从结构下极易引发复制冲突
如果在主库表上建 AFTER UPDATE 触发器往审计表写日志，从库执行相同语句时也会触发——结果就是审计表在从库多出一倍记录，甚至因主键冲突导致复制中断。真要用触发器，必须：
• 在从库禁用 log_bin_trust_function_creators 并设 sql_log_bin = OFF（仅 session 级别）
• 审计表本身不参与复制（replicate-ignore-table=db.audit_log）
• 触发器里避免调用 NOW()、UUID() 等非确定性函数，否则 STATEMENT 格式复制必然失败
主从架构下最常被忽略的点：审计不是“开了日志就完事”，而是要让主库日志、应用连接属性、网络层代理日志三者时间戳对齐，并统一用 UTC 时间存储——否则跨时区查问题时，连“谁先谁后”都判断不了。
