直接查 sys.sql_modules 最稳，因其存储视图定义且不依赖跨库路径；需在目标库执行、传完整对象名；加密视图返回 NULL，可用 OBJECT_DEFINITION 补充；比对前须用 sqlparse 归一化清洗 SQL 字符串。
直接查 sys.sql_modules 拿定义最稳
SQL Server 里视图定义就藏在 sys.sql_modules 里，只要视图没加密，SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('my_view') 就能取出来。注意：必须在目标数据库上下文中执行，比如测试库和生产库要分别连上去查，不能跨库用 db_name.schema.object 直接引用——sys.sql_modules 是数据库级视图，不认跨库路径。
- 如果视图名带架构（如
dbo.v_user_summary），OBJECT_ID()必须传完整名：OBJECT_ID('dbo.v_user_summary') - 加密视图会返回
NULL，这时得换方法，比如用OBJECT_DEFINITION(OBJECT_ID(...))，它对加密对象也返回空字符串而非报错 -
sp_helptext虽然能分段输出，但结果是多行文本，不适合脚本化提取，容易被换行干扰比对
比对前必须清洗 SQL 字符串
直接把两个 definition 字符串丢给 diff 或 Python 的 == 判断，大概率误报。因为：
- SQL Server 自动生成的语句里常含
WITH SCHEMABINDING、ENCRYPTION、ANSI_NULLS ON这类设置项，测试/生产环境创建时开关不同，但不影响逻辑 - 字段别名是否写
AS、表名是否加架构前缀（dbo.vs 省略）、空格数量、换行位置，全都会触发差异 - 注释（
--或/* */）哪怕只差一个空格，整块就被当成不同
实操建议：用 sqlparse 做词法归一化，不是格式化成好看的样子，而是统一关键字大小写、删注释、压空格。示例关键行：sqlparse.format(sql, reindent=True, keyword_case='upper').replace('\n', ' ').replace(' ', ' ').strip()
批量比对几十个视图？别手动复制粘贴
人工打开 SSMS → 右键 → “编写视图脚本为” → 复制 → 保存 → 打开另一个库重复……这活儿干十次就想辞职。真正省事的是写个 PowerShell 或 Python 脚本，自动连两个实例，遍历 sys.views，提取并清洗定义，再逐个比对。
- PowerShell 用
Invoke-Sqlcmd最快，但要注意默认返回 DataTable，取definition字段得用$row['definition']，不是$row.definition - Python 推荐用
pyodbc，连接字符串里明确指定database=xxx，避免切换上下文出错 - 比对结果别只打
True/False，记录下哪些视图不一致、差异行数、甚至输出最小 diff 片段（用difflib.unified_diff）
遇到加密视图或系统视图怎么办
sys.sql_modules 对加密视图返回 NULL，对系统视图（如 sys.dm_exec_sessions）也查不到定义——这是权限限制，不是 bug。这时候只能：
- 用
OBJECT_DEFINITION(OBJECT_ID('sys.dm_exec_sessions'))，它对系统视图有效，但返回的是内部实现伪代码，不能当真实逻辑用 - 确认是否真需要比对：系统视图定义由 SQL Server 控制，不应被修改；加密视图通常属于核心业务模块，应走发布流程同步，而不是靠比对反推
- 若必须验证加密视图行为一致性，改用数据比对：
SELECT * FROM test_db.dbo.v_sensitive EXCEPT SELECT * FROM prod_db.dbo.v_sensitive，但要注意 NULL 和排序影响结果可靠性
真正的难点不在“怎么取”，而在“取出来之后信不信”。定义字符串一致不代表行为一致——比如一个视图依赖的表在两边有不同索引，或统计信息过期，查询计划可能天差地别。定义比对只是第一道过滤，别把它当最终结论。
