sql server用sys.dm_exec_referencing_entities查依赖，postgresql查pg_depend与pg_views关联，mysql需grep导出的routine内容；均无法捕获拼接sql或orm动态语句。
如何快速定位依赖该视图的所有 SQL 对象
视图改名最直接的风险是下游对象失效，比如存储过程、函数、其他视图或应用层 SQL 直接引用了旧名。SQL Server 中可用 sys.dm_exec_referencing_entities 查依赖，PostgreSQL 则查 pg_depend 和 pg_views 关联；MySQL 8.0+ 可用 INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS 配合 ROUTINES 和 VIEWS 手动关联，但更可靠的是用 mysqldump --no-create-info --skip-triggers 导出所有 routine 内容后 grep -i '旧视图名' 检索。
注意：这些系统视图/表只记录显式引用，不捕获拼接 SQL（如 CONCAT('SELECT * FROM ', @view_name)）或 ORM 动态生成的语句，这类必须靠代码扫描或日志回溯。
ALTER VIEW 重命名是否真能“零停机”执行
在大多数主流数据库中，ALTER VIEW ... RENAME TO（PostgreSQL）、sp_rename（SQL Server）或 MySQL 的 RENAME TABLE old_view_name TO new_view_name（MySQL 视图本质是 VIEW 类型的 TABLE）本身是元数据操作，不锁表数据，但会短暂持有 Sch-M（schema modification）锁——这意味着并发的 SELECT 可能被阻塞几毫秒，而正在编译的查询计划若缓存了旧名，可能触发重新编译延迟。
- SQL Server 中
sp_rename对视图重命名后，依赖它的存储过程不会自动刷新执行计划，首次调用会失败，需手动执行EXEC sp_recompile '依赖的存储过程名' - PostgreSQL 9.6+ 的
ALTER VIEW ... RENAME TO是原子操作，但已有打开的游标（cursor）若基于旧名声明，仍会报relation "旧名" does not exist - MySQL 不支持直接
RENAME VIEW，必须DROP VIEW+CREATE VIEW，这会导致短暂不可用，且权限需重新授予
应用层 SQL 硬编码 vs ORM 映射变更怎么验证
硬编码 SQL 最难发现，尤其埋在日志分析脚本、BI 工具查询、ETL 调度 SQL 文件里。建议按以下顺序排查：
- 搜索项目代码库全部
.sql、.py、.java、.yml文件中的FROM 旧视图名或JOIN 旧视图名（注意大小写和引号包裹情况） - 检查 BI 工具（如 Tableau、Superset）的数据源定义，导出底层查询 JSON/XML，全局搜旧名
- 若用 MyBatis，重点看
<select></select>标签内文本；若用 Hibernate/JPA，检查@Query注解和 native query 字符串 - 上线前在测试环境开启全量 SQL 日志（如 MySQL 的
general_log，PostgreSQL 的log_statement = 'all'），跑一遍核心业务流，确认无relation does not exist或Invalid object name报错
为什么不能只靠“改名+测试用例通过”就上线
测试用例往往只覆盖主路径，而视图常被用于权限隔离、行级过滤或作为中间聚合层。比如一个叫 v_user_summary 的视图实际被 GRANT SELECT ON v_user_summary TO analyst_role 授权，重命名后权限不会自动迁移；又比如它被嵌套在另一个视图 v_dashboard_metrics 中，而后者又被调度任务每小时调用，这类间接依赖容易漏测。
真正安全的做法是：先在影子库（与生产结构一致但无流量）执行重命名，再用生产流量回放工具（如 pt-query-digest + 播放）验证所有 SQL 是否仍可解析执行；对关键视图，还要检查其定义中是否含 WITH CHECK OPTION（SQL Server/PostgreSQL）或确定性函数（影响物化视图刷新逻辑）——这些细节一旦忽略，上线后可能表现为数据不可见或权限静默失效。
