navicat on-prem server 的活动日志仅记录协作行为（如修改bi工作区、分享连接配置），不记录sql执行、数据变更等数据库操作；它不是数据库审计日志，也不具备拦截或记录后端sql的能力，真实审计必须依赖目标数据库自身的审计机制。

Navicat On-Prem Server 的活动日志 ≠ 数据库操作审计日志

活动日志只记录协作行为（如“张三修改了 BI 工作区”“李四分享了连接配置”），不记录任何 SQL 执行、数据变更、结构同步等数据库层操作。它本质是项目协作元数据，不是数据库审计日志。你无法靠它查到谁在哪个时间点执行了 DELETE FROM users WHERE id = 123。

On-Prem Server 本身不提供数据库级审计能力

Navicat On-Prem Server 是一个协作中枢，不是数据库代理或中间件。它不拦截、不重写、不记录用户发往后端数据库的 SQL 请求。所有真实的数据读写、DDL 变更、同步任务执行，都由客户端直连数据库完成，On-Prem Server 完全无感知。

• 它不会生成 binlog、general_log 或 audit_log
• 它不支持开启 MySQL 的 audit_log 插件，也不提供开关界面
• 所谓“审计”，在 On-Prem Server 上仅体现为 Activity Log 页面里的时间戳+用户名+动作类型

真要追踪数据库操作，必须从数据库自身入手

如果你需要知道“谁、何时、对哪张表、执行了什么语句”，唯一可靠路径是启用目标数据库的原生审计机制：

navicatmysql

Navicat For MySQL

下载

• MySQL：安装并启用 mysql-audit 插件（McAfee）或开启 general_log（仅开发环境，性能代价大）
• MySQL 8.0+：用内置 audit_log 插件，配合 audit_log_policy=ALL 和 audit_log_include_accounts
• MariaDB：启用 server_audit 插件，设置 server_audit_logging=ON，日志输出到文件或 syslog
• PostgreSQL：调整 log_statement = 'all' + log_line_prefix 包含 %u %d %h，再配合 pgAudit 扩展做细粒度控制

注意：general_log 或 audit_log 产生的日志体积极大，生产环境务必限制保留周期，并避免长期开启 log_statement = 'all'。

Navicat 客户端侧能补什么？

客户端只能补“谁在 Navicat 里干了什么”，但无法替代数据库层审计：

• Ctrl+H（历史日志）可查本机近期执行过的 SQL，但只存本地、不跨设备、不持久（重启可能清空）
• 开启 debug 日志（DebugLog=1 + LogLevel=3）能捕获同步/对比任务中实际发出的 SQL，但需手动翻 navicat_debug_*.log，且仅限当前机器
• On-Prem Server 的 Activity Log 可确认“某人是否触发了某个同步任务”，但看不到该任务内部执行了哪些 SQL、影响了多少行

真正关键的操作链条——比如“用户点击同步按钮 → Navicat 生成 17 条 UPDATE → 发往数据库执行”——只有数据库日志能完整还原最后一步。这步缺失，整个审计就是断链的。