数仓表多久没人用可以下线？没有查询日志就能直接删吗？
面试怎么回答
我会把无访问日志当作候选信号，再核对调度、视图、动态SQL和外部消费，观察窗口覆盖实际业务周期。确认负责人、替代路径和恢复要求后，先做可恢复的停产或废弃标记并观察，再按授权清理。没有日志可能是没采集到，不能直接当作无依赖；下线验收也要包含消费者迁移和恢复演练。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一张表连续三十天没有查询记录，治理脚本把它列为废表。可季度结算还没运行，历史补数也可能再次读取。低频使用，不等于没有业务价值。
无访问记录只是下线候选信号，不是无依赖证明；需要结合周期任务、动态引用、责任确认和可恢复观察期推进。
日志里没有，不代表系统里不存在
查询审计可能有保留期限、采样范围或采集遗漏。某些读请求通过缓存、外部引擎或导出文件发生，也未必出现在当前查看的日志中。
因此先确认日志覆盖哪些入口、观察了多久、是否完整，再解释“没有访问”。只有在已知观察范围内，才能说这段时间没有发现相应使用证据。
表的最后更新时间也不是使用频率。更新很久以前的维表可能仍被高频读取；每天更新的表，也可能已经没有消费者。
依赖要把直接与间接连接起来
直接依赖包括查询、调度节点和应用读取。间接依赖还包括视图链、存储过程、报表数据集、动态SQL和定时导出。
静态代码搜索可以发现候选引用，但代码仓库里的命中不一定仍在线运行；反过来，没有搜到固定表名，也不能排除通过变量拼接出的引用。
应把静态引用、运行日志、调度元数据与消费负责人确认交叉核对。目标不是依靠某一种工具证明绝对无人使用，而是把已知依赖与未覆盖范围列清楚。
观察窗口要覆盖真实业务周期
月结表可能只在月末访问，季度指标可能连续两个月没有动静。还有历史补数、审计追溯和灾备恢复，使用频率低却可能重要。
这不意味着所有表都必须永远保留，而是应根据用途确定保留与退出条件。数据生命周期、恢复成本和组织的数据保留要求，需要由相应负责人确认。
如果缺少负责人，应先解决归属或升级决策，不宜把“没人认领”自动等同于“允许删除”。孤儿资产是治理问题，不是天然的删除授权。
先退出服务，再决定物理清理
可以先标记废弃、停止新增消费者，并完成替代路径迁移。是否暂停生产任务、调整入口或进入隔离保留期，要按已有变更流程获得授权。
观察阶段记录异常访问与恢复请求，保留可执行的回退路径。回退所需的不只是表数据，还可能包括结构、权限、调度依赖、视图定义和历史版本。
不能把改名当成绝对安全的试探。改名本身也可能立即打断消费者，和删除一样需要识别影响；“可恢复”不等于“无影响”。
最终清理范围必须明确到对象与存储位置，避免误删共享文件、仍被快照引用的数据或其他表的路径。
一个典型场景：废表在季度末突然变关键
假设团队按三十天无查询筛选旧表，下线后季度报表失败。第一反应是报表临时增加了新需求，排查才发现原有季度任务一直依赖这张表。
旧验收只查看日常任务与短期查询日志，没有覆盖季度调度，也没有向指标负责人确认。表并非没人使用，只是观察窗口短于使用周期。
修正先按已验证备份恢复服务，再补全周期任务依赖，重新定义候选表的观察范围和确认清单。不能仅把阈值从三十天改成六十天，然后认为所有低频风险都消失。
之后下线计划按业务用途分组，分别安排通知、替代、观察与清理，并记录哪些使用路径仍未覆盖。
成本收益也要说完整
节省的存储与调度成本，应与迁移成本、恢复成本及保留风险一起衡量。有些大表适合降频或归档，不一定马上删除；有些重复产物在消费者迁移后，可以更快退出。
完成报告应包含已迁移消费者、已停产对象、保留恢复期限、最终清理范围与责任人。这样下一次有人问“这张表为什么没了”，能找到完整决策证据，而不只是一个自动清理任务的成功日志。