PHP如何创建审计跟踪表_PHP审计表建表法【监管】

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()）。

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 被转成空字符串）。所以每次上线新表或新增字段，必须同步更新审计日志采集逻辑，不能只靠“默认全字段”。

# ai  # 的是  # 可在  # 离线  # 如有  # 更新时间  # js  # json  # 并发  # 字符串  # 数据库  # delete  # NULL  # Token  # php  # csv  # 分区表  # mysql  # sql  # 主键  # 不能用  # 邮箱  # pdo  # table  # 应用层  # column  # dba  # 被操 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】