排查BigQuery表误删问题：审计日志查询无结果的疑问

一、查询逻辑分析与空结果的含义 #

你的查询逻辑存在两个潜在问题，空结果不一定完全代表该表90天内无操作：

1. 时间条件精度缺陷
   原SQL用DATE(timestamp) > timestamp_add(current_datetime, interval -90 day)做过滤，会丢失90天起始时刻当天的操作记录。比如当前时间是2024-05-20 14:30，90天前是2024-02-18 14:30，DATE(timestamp)会把时间戳转成日期（如2024-02-18），而timestamp_add返回带时分秒的datetime，比较时自动将日期转成当天0点，导致2024-02-18当天14:30之前的操作被过滤。正确写法应直接用时间戳字段对比：

   WHERE timestamp > timestamp_sub(current_timestamp(), INTERVAL 90 DAY)
   

2. resourceName匹配的模糊性
   protopayload_auditlog.resourceName LIKE '%MyTable%'可能匹配到其他数据集里的同名表。若要精确匹配，建议使用包含数据集的完整路径格式：

   protopayload_auditlog.resourceName = 'projects/myproject/datasets/your_dataset/tables/MyTable'
   -- 或模糊匹配特定数据集下的表
   protopayload_auditlog.resourceName LIKE 'projects/myproject/datasets/your_dataset/tables/MyTable%'
   

修正上述问题后若查询仍为空，大概率说明该表90天内没有被日志覆盖的操作，但需排除两种极端情况：

• 日志导出存在延迟（一般不超过24小时）；
• 操作由BigQuery内部服务执行（极少数场景，如系统自动清理），这类操作可能不生成常规审计日志。

二、表截断的日志记录情况 #

BigQuery中TRUNCATE TABLE属于DML操作，不属于管理员操作（管理员操作指CREATE/DROP/ALTER TABLE这类元数据变更），因此：

• 不会出现在cloudaudit_googleapis_com_activity日志中（该日志仅记录管理员级别的元数据操作）；
• 会出现在cloudaudit_googleapis_data_access日志中，但前提是配置日志导出时开启了DML操作记录（默认情况下data_access日志包含DML操作）。

若要排查表是否被截断，需确保查询范围包含cloudaudit_googleapis_data_access日志表，同时过滤protopayload_auditlog.methodName = 'google.cloud.bigquery.v2.JobService.InsertJob'，并检查protopayload_auditlog.servicedata_v1_bigquery.jobCompletedEvent.job.jobConfiguration.query.query字段是否包含TRUNCATE TABLE语句。

内容的提问来源于stack exchange，提问作者red888