Navicat查询控制台默认只显示执行摘要（如“10 row(s) returned”），不打印真实SQL、参数、耗时或错误堆栈，因其本质是交互式编辑器，仅解析数据库协议响应；完整日志需手动启用DebugLog=1和LogLevel=3配置，生成于本地logs/目录，但仅反映客户端发出动作，不可替代数据库层审计。
Navicat 查询控制台输出的日志默认只显示 SQL 执行的摘要结果（如“1 row(s) affected”），不记录实际执行的 SQL 语句、参数绑定值、执行耗时或错误堆栈——这不是 bug，而是设计如此；完整日志必须主动开启调试模式并配合外部验证手段。
查询控制台为什么只显示“执行成功/失败”，不打印真实 SQL？
Navicat 的查询窗口本质是交互式 SQL 编辑器，不是命令行客户端。它把用户输入的 SQL 提交给数据库执行后，仅解析 MySQL/PostgreSQL 等返回的协议级响应（如 OK packet 或 Error packet），然后在控制台渲染成简洁提示。它不会自动回显你发了什么、带什么参数、用了多少时间。
-
SELECT * FROM users LIMIT 10执行后，控制台只显示“10 row(s) returned”，不会出现该语句本身 - 带变量的查询（如
SELECT ?配合参数面板）也不会记录传入的实际值 - 批量执行多条语句时，只按“语句块”计数，不逐条标记哪条报错
如何让 Navicat 记录完整执行日志（含 SQL、参数、耗时）？
必须启用内部调试日志，且仅对 Windows/macOS 桌面版有效；Navicat 不提供 GUI 开关，需手动修改配置文件。
- 关闭 Navicat，编辑配置文件：
%APPDATA%\PremierSoft\Navicat Premium\config.ini（Windows）或~/Library/Application Support/PremierSoft/Navicat Premium/config.ini（macOS） - 在
[General]段下添加两行：DebugLog=1和LogLevel=3 - 重启 Navicat，执行任意查询后，日志会生成在
logs/子目录下，文件名形如navicat_debug_20260907.log - 日志中可搜索
SQL:前缀行，看到完整语句；含bind param的行即参数值；每条记录带毫秒级时间戳
常见误操作：以为“日志”能替代数据库层审计
即使开启了 DebugLog=1，这些日志也只存在于客户端本地，不上传、不持久、不防篡改——它帮你复盘“Navicat 发了什么”，但无法回答“数据库里到底改了哪些行”。
- 日志不包含事务提交前的中间状态（比如
UPDATE影响了哪几行，只记“Rows matched: 5”） - 如果 Navicat 异常退出，
navicat_debug_*.log可能截断，最后一段丢失 - 生产环境变更追溯，必须依赖数据库自身能力：MySQL 的
binlog、PostgreSQL 的pg_log或逻辑复制槽 - 想查某次
DELETE删了谁？别翻 Navicat 日志，直接查数据库的information_schema.PROCESSLIST（实时）或慢日志表（事后）
真正容易被忽略的是：Navicat 调试日志只记录客户端视角的“发出动作”，而数据库是否真正执行、是否被触发器拦截、是否因约束失败静默跳过——这些都得看数据库自己的 error log 或 general_log（若已开启表存储）。
