query profiler 启用需 performance_schema 开启且用户有 select 权限；profile 页签显示执行状态阶段耗时，但真实 io 压力需结合 show profile io 和 explain 综合判断。
query profiler 的启用前提：确认 performance_schema 已开启
navicat 的 query profiler 依赖 mysql 的 performance_schema，如果该库被禁用或权限不足，profile 页签会灰显或提示“unable to show performance schema”。这不是 navicat 本身的问题，而是服务端配置缺失。
检查方式（在 Navicat 查询窗口中执行）：SELECT @@performance_schema; —— 返回 1 才有效SHOW ENGINE PERFORMANCE_SCHEMA STATUS; —— 确认状态为 OK
- 若返回
0，需在 MySQL 配置文件（my.cnf或my.ini）中添加performance_schema = ON并重启 MySQL - 普通用户可能无权访问
performance_schema表，需 DBA 授予SELECT权限：GRANT SELECT ON performance_schema.* TO 'your_user'@'%'; - Navicat Monitor v2.9.0+ 支持 PostgreSQL 的 SQL Profiler，但 PostgreSQL 的 IO 指标来源是
pg_stat_statements和pg_statio_*视图，与 MySQL 机制不同
Profile 页签里哪些指标反映 IO 压力
执行完查询后切换到 Profile 页签，重点看以下几列：
-
state：状态阶段名，如Creating sort index、Copying to tmp table、Writing to net—— 这些阶段若耗时长，往往伴随磁盘临时表或排序溢出 -
Duration：单阶段耗时，单位秒；IO 密集型操作（如全表扫描、大结果集排序）常在executing或Sending data阶段停留过久 -
Source_function和Source_file：可定位到 MySQL 内部函数，比如mysql_update或handler::ha_read_range，间接反映是否触发了索引失效导致回表/全扫
注意：Profile 页签不直接显示“读取多少页”或“物理 IO 次数”，它展示的是语句执行过程中的状态流。真正的 IO 量化需结合 EXPLAIN FORMAT=JSON 中的 used_columns、rows_examined，或 SHOW PROFILE IO FOR QUERY N;（MySQL 5.7+ 支持）
对比 SHOW PROFILE IO 与 Navicat Profile 页签的差异
Navicat 的 Profile 页签本质是图形化封装了 SHOW PROFILE，但它默认只显示基础状态（ALL），不自动展开 IO 维度。想看到磁盘读写详情，必须手动补查：
- 先执行目标 SQL（例如
SELECT * FROM orders WHERE created_at > '2025-01-01';） - 再在同个连接中运行：
SHOW PROFILE IO FOR QUERY 1;（数字对应最近一次查询 ID） - 关注输出中的
IO read bytes、IO write bytes、IO fsyncs字段 —— 这才是真实 IO 压力的量化依据 - Navicat 不支持直接执行
SHOW PROFILE IO后自动映射到 Profile 页签，必须人工比对
常见误判：看到 Sending data 耗时 2.3s 就认定是网络慢，其实可能是 handler::read_range 在从磁盘批量读取二级索引+主键，然后回表构造结果集 —— 真正瓶颈在 IO，而非网络
云数据库（如 RDS/Aurora）上 Profile 页签不可用的典型原因
阿里云 RDS、AWS Aurora 等托管服务通常禁用 performance_schema 或限制 SHOW PROFILE 权限，此时 Navicat 的 Profile 页签会空白或报错 Access denied for user。
- 替代方案：用 Navicat Monitor 的「查询分析器」+「慢查询」模块，它通过定期抓取
slow_log和performance_schema.events_statements_summary_by_digest（若开启）聚合 IO 相关指标 - 阿里云 RDS 可开启「SQL 审计」并导出 CSV，筛选
query_time高且rows_examined大的语句，再用EXPLAIN分析是否缺失索引 - 不要依赖
SET profiling = 1—— 该命令在 MySQL 8.0 中已被废弃，且云厂商普遍屏蔽
Profile 页签看着直观，但真正判断 IO 压力得靠三层交叉验证：状态阶段耗时 + SHOW PROFILE IO 数值 + EXPLAIN 的 type 和 rows。漏掉任意一层，都容易把内存排序误判为磁盘 IO，或者把锁等待当成 IO 瓶颈。
