navicat显示的执行时间不准确——它是客户端往返时间（含网络延迟、锁等待等），非服务端真实执行耗时；真实耗时应查看结果集下方info标签页中数据库返回的原始统计，如mysql的“(0.042 sec)”、postgresql的“time: 0.037 ms”。
直接在 navicat 里看执行时间不靠谱，explain 输出也容易误读——innodb 和 myisam 的性能差异根本不在“点一下就出结果”的层面，而藏在锁机制、统计方式、索引结构这些底层行为里。
为什么 Navicat 的“运行时间”不能直接比？
Navicat 执行查询后显示的耗时，是客户端从发请求到收到全部结果的总延迟，混入了网络、客户端解析、缓冲区刷盘等干扰项。更关键的是：
- MyISAM 的
SELECT COUNT(*)几乎瞬间返回，因为它直接读内存里缓存的行数；InnoDB 必须扫描聚簇索引或采样估算，真实耗时取决于数据量和隔离级别 - 带
WHERE条件的查询，如果走不到索引，MyISAM 表级锁会阻塞其他写操作，而 InnoDB 行锁可能让并发读写看似“更快”，但实际要看事务是否冲突 - Navicat 默认开启自动提交（autocommit=1），对 MyISAM 没影响，但对 InnoDB 每条语句都隐式开启/提交事务，会放大日志写入开销
真正该盯住的三个 Navicat 可查指标
在 Navicat 中右键表 →「对象信息」→「统计信息」或执行以下语句，重点关注：
-
SHOW TABLE STATUS LIKE 'table_name'：看Rows字段——MyISAM 是准的，InnoDB 是估算值（误差常达 40%+）；Engine确认类型；Data_length和Index_length能反映聚簇 vs 非聚簇索引的空间占用差异 -
SHOW INDEX FROM table_name：InnoDB 的主键索引（Key_name=PRIMARY）直接包含数据行，而 MyISAM 的PRIMARY索引只存地址；若没主键，InnoDB 会自建隐藏聚簇索引，查询性能可能意外下降 - 执行
EXPLAIN SELECT ...后看type和key：MyISAM 对LIKE '%abc'基本无法用索引，InnoDB 同样不行；但若用LIKE 'abc%'，两者都能走索引——区别在于 InnoDB 的rows估算更保守，MyISAM 更乐观
ALTER TABLE ENGINE=... 切换引擎前必须验证的点
在 Navicat 中右键表 →「设计表」→「选项」改引擎，或手动执行 ALTER TABLE t ENGINE=MyISAM，但要注意：
- MyISAM 不支持外键，切换前
SHOW CREATE TABLE t若含FOREIGN KEY，语句会静默失败或丢弃约束 - InnoDB 表若含全文索引（
FULLTEXT），切到 MyISAM 会保留，但切回来会报错——MyISAM 支持全文索引，InnoDB 5.6+ 才支持，版本不匹配直接失败 - 切换过程会锁表。MyISAM 表锁期间所有写入阻塞；InnoDB 行锁但 DDL 仍需元数据锁（MDL），高并发下可能卡住其他查询
- 切换后立刻执行
ANALYZE TABLE t：MyISAM 更新统计快，InnoDB 的统计更新是异步且采样的，不手动触发可能导致后续执行计划劣化
最易被忽略的是：InnoDB 的 innodb_stats_persistent 开关。如果关着，每次重启 MySQL 统计都会重置，Navicat 里看到的 Rows 值就完全不可信——而这个参数默认在 MySQL 5.6.6+ 是开启的，老环境却常被忽略。
