Navicat的Profile页签仅显示各阶段wall-clock耗时，不包含真实I/O指标；需用SHOW PROFILE IO FOR QUERY N获取IO read/write bytes及fsyncs，结合EXPLAIN FORMAT=JSON或PostgreSQL的EXPLAIN (ANALYZE, BUFFERS)定位物理I/O来源。
Navicat 的 Profile 页签不直接显示 I/O 消耗
profile 页签只是图形化封装了 show profile，默认只展示各执行阶段（如 sending data、creating sort index）的 wall-clock 耗时，并不包含磁盘读写字节数、fsync 次数等真实 i/o 指标。看到某阶段耗时长，不能直接断定是 i/o 瓶颈——也可能是锁等待、cpu 密集计算或网络传输慢。
真正反映物理 I/O 的字段必须通过显式命令获取：
-
SHOW PROFILE IO FOR QUERY N（MySQL 5.7+），输出中关注IO read bytes、IO write bytes、IO fsyncs -
EXPLAIN FORMAT=JSON中的rows_examined和used_columns，结合表引擎（如 InnoDB 的 page size）可估算逻辑读页数 - PostgreSQL 需用
EXPLAIN (ANALYZE, BUFFERS)，看Buffers: shared hit/read/dirty和IO read time
启用前必须确认 performance_schema 已开启且有权限
Navicat 的 Profile 页签灰显或提示 “unable to show performance schema”，大概率不是客户端问题，而是服务端配置缺失：
- 执行
SELECT @@performance_schema;—— 必须返回1，否则在 MySQL 配置文件（my.cnf或my.ini）中添加performance_schema = ON并重启 - 普通用户默认无权访问
performance_schema表，需 DBA 执行：GRANT SELECT ON performance_schema.* TO 'your_user'@'%'; - MySQL 8.0+ 已弃用
SET profiling = 1，别再依赖它；performance_schema是唯一可靠路径
MySQL 中查 I/O 的最小可行操作流
在 Navicat 查询窗口中按顺序执行以下三步（必须在同一连接内）：
- 运行目标 SQL：
SELECT * FROM orders WHERE created_at > '2025-01-01'; - 立即执行：
SHOW PROFILE IO FOR QUERY 1;（数字 1 表示最近一次查询；若中间执行过其他语句，先用SHOW PROFILES;查 ID） - 重点比对两列：
Duration（该阶段总耗时）和IO read bytes（该阶段实际读取的磁盘字节数）；若后者极大但Duration很小，说明 SSD 或 buffer pool 命中率高；若两者都大，才是真 I/O 压力
注意：SHOW PROFILE IO 不会告诉你“哪张表被扫了”，要定位具体对象，得配合 EXPLAIN FORMAT=JSON 里的 table_name 和 access_type 字段。
别把 Navicat 状态栏耗时当 I/O 指标
右下角状态栏显示的 “0.245s” 是客户端视角的总耗时：含网络往返、SQL 解析、结果集序列化与传输。它和数据库内部的物理 I/O 完全无关。哪怕 SELECT COUNT(*) FROM huge_table 在 buffer pool 全命中、零磁盘读，状态栏仍可能显示几百毫秒——只是因为结果集太大传得慢。
真正想量化 I/O，必须绕过客户端计时，直连数据库服务端指标。最容易被忽略的一点是：I/O 压力往往藏在临时表和排序阶段，而不是主表扫描本身。所以看到 Copying to tmp table 或 Sorting result 耗时突增，第一反应不该是加索引，而是检查 sort_buffer_size、tmp_table_size 是否过小导致落盘。
