Navicat右下角耗时不可信，应查Profile页签中Sending data的Percentage占比（超70%即锁定问题）；需启用performance_schema并执行SHOW PROFILE IO FOR QUERY 1，结合回表、索引覆盖及innodb_buffer_pool_size配置综合优化。
直接看 Sending data 占比，别信状态栏耗时
Navicat 右下角显示的 “0.245s” 是客户端总耗时，含网络、解析、序列化，和 Sending data 的真实工作量无关。真正要判断是不是这个阶段卡住，必须打开 Profile 页签（查询执行后点击顶部菜单「查询」→「分析」或直接点结果窗口右上角 Profile 图标），重点看 Sending data 行的 Percentage —— 如果超过 70%，基本可锁定问题出在数据收集环节，不是网络慢。
确认是否因回表或大字段导致
回表是 Sending data 耗时长的最常见原因：索引快速定位了 row_id，但 SELECT 的字段（如 description、content）不在索引里，MySQL 得反复回聚簇索引捞整行。验证方法很直接：
- 在同个 Navicat 连接中，先运行目标 SQL，再立刻执行
SHOW PROFILE FOR QUERY 1;（数字 1 表示最近一次查询；若中间执行过其他语句，先用SHOW PROFILES;查 ID） - 对比
Sending data和Creating sort index两行的Duration：若前者远大于后者，且你 SELECT 里包含未建索引的 TEXT/VARCHAR 大字段，大概率就是它 - 临时删掉可疑字段重跑，比如把
SELECT *, updated_at改成SELECT id, name，观察耗时是否从 3.2s 降到 0.15s
别用 SET profiling = 1，改走 performance_schema
MySQL 8.0+ 已弃用 SET profiling = 1，Navicat 的 Profile 页签底层依赖它，但服务端若禁用 performance_schema，页签会灰显或报 “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'@'%'; - 启用后，
SHOW PROFILE IO FOR QUERY N;才能拿到真实 I/O 字节数，帮你区分是磁盘读慢（IO read bytes大 +Duration大），还是 buffer pool 命中率高（IO read bytes小但Duration大）
优化方向很具体，别只盯着“加索引”
覆盖索引是最有效的解法，但容易被忽略的细节是字段顺序和隐式转换：
- 如果查询是
WHERE user_id = ? ORDER BY created_at DESC，索引必须是(user_id, created_at)，反过来就无效 -
WHERE UPPER(name) = 'ABC'会让任何name上的索引失效，得改成WHERE name = 'abc'并确保 collation 支持大小写不敏感 - 复合索引里包含大字段（如
VARCHAR(2000)）会显著增大 B+ 树体积，降低缓存效率，宁可拆成两个索引：(user_id, created_at)+ 单独的description索引（仅当真需要按 description 查询时）
buffer pool 太小也会放大 Sending data 开销——innodb_buffer_pool_size 默认仅 32M，查 200MB 的表等于每行都刷盘。调到物理内存的 50%～75%（如 16GB 机器设为 8G），重启 MySQL 后再测，常有数量级提升。
