在大型系统的数据库架构里，视图常被用来封装复杂查询或做权限隔离。随着业务变更，一些视图字段在最初设计后有调用方不再读取，却仍保留在定义中。这类未使用列不仅让视图定义变得臃肿，也会在查询时增加不必要的投影与IO。通过代码静态分析与扫描技术，可以在不运行数据库的情况下找出这些死角。
为什么需要检测视图中的未使用列
视图本质上是一条被保存的SELECT语句。当上层服务、报表脚本或存储过程不再引用其中某些列时，数据库优化器虽可能做一定裁剪，但定义本身依旧维护着这些字段的元数据，并在权限校验、视图嵌套展开时带来额外开销。更重要的是，冗余列会误导新接手开发的同事，让他们误以为前端依赖这些字段，从而不敢做表结构演进。
人工排查往往从information_schema出发，逐个人肉比对代码仓库，效率低且容易遗漏动态拼接SQL的场景。静态分析与扫描工具则能把视图定义和代码调用方放在同一分析平面，用程序化的方式给出确定结论，这在拥有上百个视图与多语言服务仓库的项目中价值尤其明显。
基于静态分析的核心思路
整个检测过程可以拆成两个独立阶段：视图定义抽取与引用扫描。第一阶段从数据库元数据中拿到视图的SELECT列表，把每个输出列的真实名字与别名记录下来；第二阶段在代码仓库里扫描所有可能对视图发起查询的语句，提取被选中的列名，再取差集。
难点在于SQL的灵活性。视图可能被SELECT *直接消费，也可能在ORM里被映射成实体类，只有部分属性被读取。因此静态分析不能只做字符串匹配，而要构建轻量抽象语法树（AST），识别查询节点中的投影列，并与视图输出列做语义对齐。
视图定义抽取示例
下面是一段从PostgreSQL系统表读取视图列的Python代码，它把视图名与列名整理成映射，供后续比对使用。
import psycopg2
def extract_view_columns(conn, view_name):
# 查询系统目录拿到视图输出列
sql = "SELECT column_name FROM information_schema.view_column_usage "
"WHERE view_name = %s"
cur = conn.cursor()
cur.execute(sql, (view_name,))
rows = cur.fetchall()
return [r[0] for r in rows]
# 假设已建立连接
# cols = extract_view_columns(conn, 'user_summary_view')
# print(cols)
这段代码仅做示意，实际项目中还需要处理视图依赖其他视图的嵌套情况，也就是递归展开底层表列，才能知道最上游的真实字段。
代码仓库中的列引用扫描
拿到视图列清单后，要在代码侧找引用。对于Java里的MyBatis映射或Go里的原生SQL字符串，可以用正则配合AST解析提取SELECT子句。下面给出一个简单的静态扫描伪代码，演示如何统计某列是否在仓库文本中出现。
import os
import re
def scan_column_usage(repo_path, column_name):
# 简单扫描仓库中是否出现该列名
pattern = re.compile(r'b' + re.escape(column_name) + r'b')
hit_files = []
for root, _, files in os.walk(repo_path):
for f in files:
if f.endswith('.sql') or f.endswith('.py') or f.endswith('.java'):
path = os.path.join(root, f)
with open(path, 'r', encoding='utf-8') as fh:
if pattern.search(fh.read()):
hit_files.append(path)
return hit_files
# unused = [c for c in view_cols if not scan_column_usage('/repo', c)]
这种扫描在动态SQL拼接时可能误报，比如列名由变量控制。因此在生产级工具里，通常会接入语言服务器协议或专用SQL解析器，把字面量与变量使用都纳入数据流分析，从而降低噪音。
完整扫描流程设计
把上述思路工程化，可归纳为如下步骤：连接元数据获取视图清单、递归解析视图定义生成列集合、克隆代码仓库并做词法或语法级扫描、生成未使用列报告、人工复核后执行视图改写。
| 阶段 | 输入 | 输出 |
|---|---|---|
| 元数据抽取 | 数据库连接 | 视图到列的映射表 |
| 代码扫描 | 仓库路径、列映射 | 列到引用文件的映射 |
| 差集计算 | 两份映射 | 未使用列清单 |
| 复核清理 | 清单与评审 | 新版视图DDL |
上表给出了各阶段的边界，团队可以据此把任务分给DBA与研发分别执行。值得注意的是，某些列虽在应用代码未出现，却可能被定时报表或BI工具直连使用，所以报告必须包含调用方类型分布，避免误删。
落地时的注意事项
静态分析只能证明代码文本中无引用，不能替代运行时追踪。若系统存在纯动态SQL或外部SaaS通过API间接查视图，扫描结果要结合网关日志做交叉验证。另外，在改写视图删除列之前，务必在预发环境用EXPLAIN确认执行计划无回归。
对于使用了ORM自动映射全部字段的仓库，建议暂时把实体类字段标记为废弃并观察一个发布周期，再真正从视图DDL里拿掉列。这样即便静态分析漏掉某个反射读取路径，也能通过监控兜底发现。
小结
检测SQL视图中未使用的列，核心是把数据库元数据与代码仓库放在静态分析框架下做交集差分。借助AST与系统化扫描，团队可以用很低的人力成本持续清理冗余schema，保持视图定义与真实消费方一致，为后续表结构演进扫清认知障碍。