navicat本身不记录视图修改人，也不提供内置审计日志；真正可查的修改痕迹需依赖数据库层ddl审计（如mysql的general_log或audit_log、postgresql的pg_stat_operations），且须提前开启配置并手动查询，或通过navicat执行带标准注释的sql并纳入git版本控制实现人工留痕。
Navicat 本身不记录视图修改人，也无内置审计日志；真正可查的修改痕迹取决于数据库是否启用 DDL 审计，且需人工配合留痕或工具辅助。
MySQL 8.0+ 查 mysql.general_log 或 mysql.audit_log（需提前开启）
Navicat 不解析、不展示服务器端日志，但你可以用它连上数据库后手动查审计表：
-
general_log记录所有语句（含CREATE OR REPLACE VIEW），但默认关闭，开启后性能开销大；需确认general_log = ON且log_output = 'TABLE' -
audit_log插件更精准（只记 DDL/DML），但需安装、配置，并赋予用户SELECT权限到mysql.audit_log表 - 执行示例：
SELECT * FROM mysql.general_log WHERE argument LIKE '%CREATE%VIEW%your_view_name%' ORDER BY event_time DESC LIMIT 5; - 注意：日志里没有“用户名”字段，只有
user_host，得靠 IP + 登录时间反推操作人
PostgreSQL 查 pg_stat_operations（需 log_statement = 'ddl'）
Navicat 可以执行查询，但不会自动关联会话信息：
- 必须在
postgresql.conf中设置log_statement = 'ddl'并重启服务，日志才写入pg_stat_operations - 查法：
SELECT * FROM pg_stat_operations WHERE object_identity = 'your_schema.your_view_name' AND action = 'CHANGE' ORDER BY occurance DESC; -
objid和classid是 OID，usename字段才对应实际修改人——但该字段仅当log_line_prefix包含%u时才可靠 - Navicat 的「对象信息」或右键菜单完全不暴露这些字段，必须自己写 SQL
绕过数据库限制：用 Navicat + 版本控制强制留痕
这是目前最可控、零依赖数据库配置的做法：
- 所有视图变更必须走 Navicat 的「查询」窗口执行，禁止用「设计视图」右键 → 「编辑」（它不生成可追溯 SQL）
- 每次执行前，在 SQL 开头加标准注释：
-- @author alice -- @date 2026-09-07 -- @reason 修复 join 条件漏判 - 把所有
.sql文件纳入 Git，提交时检查注释完整性；用git blame直接定位最后修改人 - Navicat 的「查询」列表里保存的脚本，若未执行，不会进数据库，也不会被「数据库范围搜索」扫到——所以必须执行并 commit
真正容易被忽略的是：Navicat 的「查找对象」功能能搜出谁引用了这张视图，但查不出谁改了它；而数据库层的审计能力，90% 的生产环境默认是关着的。留痕这件事，没法交给工具自动完成，得靠流程卡点。
