audit_log表必须包含id、table_name、record_id、action、old_values、new_values、user_id、ip_address、created_at九个字段，其中old_values和new_values须用JSON或LONGTEXT类型存储，created_at需支持微秒精度。
审计表必须包含哪些字段
监管类系统要求审计数据不可篡改、可追溯，所以表结构不能只记“谁改了什么”。audit_log 至少得有：id（主键）、table_name（被操作的表名）、record_id（被操作记录的主键值）、action（INSERT/UPDATE/DELETE）、old_values 和 new_values（JSON 格式存变更前/后字段快照）、user_id（操作人ID）、ip_address、created_at（用 DATETIME(6) 支持微秒，避免高并发下时间重复）。
特别注意：old_values 和 new_values 必须用 JSON 类型（MySQL 5.7+）或 LONGTEXT（兼容旧版），不能用 TEXT —— 后者可能被截断且无 JSON 校验。
如何用 PDO 自动捕获变更数据
手动拼 INSERT INTO audit_log 容易漏字段、错顺序，也难覆盖所有业务入口。推荐在 DAO 层统一拦截。关键不是“记录 SQL”，而是“记录语义”：在执行 $pdo->prepare() 前，把原始数据和预期变更提取出来。
function logAudit($pdo, $table, $action, $recordId, $oldData, $newData, $userId, $ip) {
$stmt = $pdo->prepare("INSERT INTO audit_log (table_name, record_id, action, old_values, new_values, user_id, ip_address, created_at) VALUES (?, ?, ?, ?, ?, ?, ?, NOW(6))");
$stmt->execute([
$table,
$recordId,
$action,
json_encode($oldData, JSON_UNESCAPED_UNICODE),
json_encode($newData, JSON_UNESCAPED_UNICODE),
$userId,
$ip
]);
}
调用示例（更新用户邮箱）：
$old = ['email' => 'a@old.com', 'status' => 1]; $new = ['email' => 'b@new.com', 'status' => 1]; logAudit($pdo, 'users', 'UPDATE', 123, $old, $new, 456, $_SERVER['REMOTE_ADDR']);
注意点：
• json_encode() 必须加 JSON_UNESCAPED_UNICODE，否则中文变 \uXXXX，查起来反人类；
• 不要直接传 $_POST 或 $_GET，先过滤空值和敏感字段（如密码、token）；
• $recordId 对 INSERT 可为 NULL，但需在触发器或应用层确保能回溯到刚插入的 ID（比如用 $pdo->lastInsertId()）。
立即学习“PHP免费学习笔记（深入）”；
MySQL 触发器补位方案（慎用）
如果部分老代码绕过 PHP 直连数据库（如定时任务用 mysqldump 或 DBA 手工 UPDATE），纯 PHP 日志会漏。这时可在关键表上加 AFTER INSERT/UPDATE/DELETE 触发器，但仅限补位，不替代应用层日志。
常见陷阱：
• 触发器里不能用 UUID() 或 NOW(6) 做主键，会导致从库复制失败（非确定性函数）；
• NEW 和 OLD 在 INSERT 中没有 OLD，DELETE 中没有 NEW，写错会报错 Unknown column 'OLD.xxx' in 'field list'；
• 触发器无法获取 user_id 和 ip_address，只能填默认值（如 'system'）或留空，监管检查时会被质疑责任主体缺失。
所以真正合规的做法是：PHP 层日志为主，触发器仅用于兜底 + 告警，且必须配合审计字段校验（比如检查 audit_log.created_at 是否比业务表更新时间晚超过 5 秒，触发告警）。
索引与归档策略直接影响监管验收
审计表增长极快，不做处理几个月就卡死查询。监管系统常要求“保留 180 天以上”，但没说必须在线可查。实际做法分三层：
• 当前热表（最近 30 天）：在 (table_name, record_id, created_at) 上建联合索引，支撑按业务单据查全生命周期；
• 历史分区表（按月 PARTITION BY RANGE COLUMNS(created_at)）：MySQL 8.0+ 支持，删除旧分区比 DROP TABLE 更安全；
• 冷数据归档：导出为加密 CSV + SHA256 校验码，离线存储，满足“不可抵赖”要求。
最容易被忽略的是：监管检查时会抽样验证某条业务操作是否在审计表中存在对应记录，并核对 old_values/new_values 的 JSON 结构是否完整（比如有没有字段丢失、null 被转成空字符串）。所以每次上线新表或新增字段，必须同步更新审计日志采集逻辑，不能只靠“默认全字段”。
