navicat 17 不支持查询级内存监控，因其无内置探针或内存采样机制，sql预览和执行计划视图均不显示memory used等内存字段；需通过数据库原生命令（如postgresql的explain analyze、mysql的performance_schema）获取真实内存使用情况。
Navicat 17 不提供查询级内存分配与释放的实时监控能力。 它没有内置探针、堆栈跟踪或内存采样机制，无法像 EXPLAIN ANALYZE（PostgreSQL）或 performance_schema（MySQL）那样暴露每一步操作的内存占用变化。
为什么“SQL预览”或“查询编辑器”里看不到内存数据
Navicat 的 SQL预览 标签只响应 DDL 结构变更，和运行时资源无关；查询编辑器的“执行计划”视图仅展示索引选择、扫描类型、行数估算等逻辑信息，Memory Used、Peak Memory 这类字段在 Navicat UI 中根本不存在。它不解析或转发数据库引擎返回的底层内存统计字段（如 PostgreSQL 的 Buffers 或 Memory: 2048kB 行）。
真正能查到内存行为的地方：必须进数据库原生命令行或系统表
想确认某条复杂查询实际用了多少内存、是否触发了磁盘临时排序或哈希表溢出，得绕过 Navicat 的 GUI 层：
- PostgreSQL：在 Navicat 查询窗口中手动执行
EXPLAIN (ANALYZE, BUFFERS, SETTINGS) SELECT ...，重点关注输出里的Memory: xxxkB、Work_mem used、Sort Method: external merge Disk等行 - MySQL 8.0+：启用
performance_schema后查performance_schema.memory_summary_events_by_thread_by_event_name，或用SHOW PROFILE memory FOR QUERY N（需先开SET profiling = 1） - SQL Server：用
SET STATISTICS XML ON查执行计划中的MemoryGrantInfo节点，或查sys.dm_exec_query_memory_grants
Navicat 能帮你做的有限但关键的事
它不显示内存，但能降低你误判内存风险的概率：
- 在写子查询或 CTE 时，用
EXPLAIN按钮（不是“执行”按钮）快速看是否走了 Nested Loop → 避免小表驱动大表导致内存暴涨 - 对
ORDER BY/GROUP BY字段，提前在 Navicat 的“索引”标签页确认有覆盖索引 → 减少Using filesort或Using temporary - 执行前右键查询窗口 → “格式化 SQL”，避免因括号错位、隐式类型转换导致优化器选错路径，间接引发内存失控
- 如果查询含大量
UNION ALL或嵌套 JSON 解析（如jsonb_path_query），Navicat 的语法高亮会标红报错 → 提前拦截语法错误，防止执行卡死在解析阶段
真正容易被忽略的是：内存压力往往来自并发而非单条语句。Navicat 的“连接”设置里默认 Max Connection Pool Size 是 50，但如果你在多个标签页同时跑 SELECT * FROM huge_table，每个连接都申请 work_mem，加起来就超了。这时候要调的不是查询本身，而是连接池配置或数据库侧的 work_mem 限值。
