InnoDB无主键时自动创建隐藏主键保障聚簇索引，MyISAM无主键则无索引依赖；回表时InnoDB需二次B+树查找主键，MyISAM直接物理寻址；排序是否走索引取决于索引结构而非引擎。
为什么主键缺失时InnoDB能查，MyISAM却可能出错？
InnoDB 表没显式定义 PRIMARY KEY 时，MySQL 会悄悄加一个隐藏的 6 字节自增主键（类型为 BIGINT），确保聚簇索引能建起来；而 MyISAM 完全不强制主键，没主键就是没主键——它压根不需要靠主键组织数据。
这意味着：如果你用 SELECT * FROM t WHERE id = ? 查询，但 id 列没建索引，InnoDB 还得走聚簇索引（也就是整张表）扫描；MyISAM 同样全表扫，但更糟的是，某些旧版客户端或 ORM 在生成执行计划时，会误判“无主键=无可靠排序/分页依据”，导致 LIMIT、ORDER BY 结果不稳定。
- MyISAM 表导出再导入后丢失主键信息，
SHOW CREATE TABLE里看不到PRIMARY KEY，但业务代码仍按有主键逻辑写 SQL，容易引发隐式类型转换或空值比较异常 - InnoDB 的隐藏主键不可见、不可引用（比如不能在
JOIN或ORDER BY中写它），但会真实占用空间、影响INSERT性能，尤其高并发写入时 - 迁移老 MyISAM 表到 InnoDB 前，务必用
ALTER TABLE t ENGINE=InnoDB;+ 显式添加PRIMARY KEY，否则等于把隐患打包带走
回表到底是查地址还是查主键？性能差在哪？
MyISAM 的二级索引叶子节点存的是数据行在 .MYD 文件里的物理偏移量（比如第 12403 行），查完索引直接按地址读磁盘；InnoDB 的二级索引叶子节点存的是对应记录的 PRIMARY KEY 值，查完还得拿着这个主键值，再去聚簇索引（即主键索引）B+ 树里再搜一遍——这就是“回表”。
表面看多一次 B+ 树查找，实际代价更高：MyISAM 的地址访问是顺序/局部性极好的随机读，InnoDB 回表大概率触发另一次磁盘随机 IO（除非主键刚好缓存在 buffer pool），尤其当主键是 UUID 这类离散值时，性能落差明显。
- 用
EXPLAIN看type是ref但Extra出现Using index condition，说明走了索引下推，但依然要回表——这时如果 SELECT 的字段都在索引里，就该建覆盖索引 - MyISAM 的
.MYI和.MYD文件可分别放在不同磁盘，靠系统层优化 IO；InnoDB 的数据和索引混在同一个.ibd文件里，IO 路径更长，buffer pool 压力更大 - 别迷信“MyISAM 回表快”，它的快建立在数据静态、无事务、无 MVCC 的前提上；一旦加上
UPDATE或DELETE，MyISAM 锁整张表，InnoDB 锁行，实际混合负载下 MyISAM 往往更慢
order by a,b 走不走索引，取决于存储引擎吗？
不取决于引擎类型，而取决于索引结构本身是否匹配排序需求。InnoDB 和 MyISAM 都支持 B+ 树索引，只要建了 INDEX idx_ab (a,b)，那么 ORDER BY a ASC, b ASC 或 ORDER BY a DESC, b DESC 都能直接利用索引顺序输出，无需 Using filesort。
但关键差异在于：InnoDB 的聚簇索引让 ORDER BY PRIMARY KEY 天然有序，而 MyISAM 数据文件本身无序，即使你 ORDER BY id，若 id 不是索引列，照样全表扫描+排序。
-
ORDER BY a DESC, b ASC这种混合方向，在 MySQL 8.0+ 才被真正支持利用索引；老版本（如 5.7）哪怕建了(a,b)索引，也会触发Using filesort - MyISAM 表做
ALTER TABLE ... ORDER BY id可以物理重排.MYD文件，让顺序访问变快，但这是一次性操作，后续写入又打乱；InnoDB 没这招，聚簇索引天然维持主键顺序 - 别为了
ORDER BY单独建索引——先看查询是否高频、是否已带WHERE条件；否则很可能建了个“只服务排序、不服务过滤”的低效索引
什么时候必须选 InnoDB？MyISAM 真的完全淘汰了吗？
只要业务涉及事务、外键、崩溃恢复、高并发写、或者未来可能分库分表，InnoDB 就不是“推荐”，而是“必须”。MyISAM 唯一还站得住脚的场景只剩两类：超大只读归档表（比如日志快照）、或全文检索且不关心事务的简单搜索（MATCH ... AGAINST 在 MyISAM 上更轻量）。
但注意：MySQL 8.0 已移除 MyISAM 的全文索引停用词表热加载能力，且 innodb_ft_enable_stopword 等参数让 InnoDB 全文也足够灵活；而 MyISAM 表损坏后修复困难，REPAIR TABLE 经常失败。
- 线上环境禁用 MyISAM：Docker 镜像、云数据库 RDS 默认禁用，
show engines;查到MyISAM的SUPPORT字段已是NO或DISABLED - 历史遗留 MyISAM 表迁移前，先用
mysqldump --no-create-info --skip-triggers导出数据，再CREATE TABLE ... ENGINE=InnoDB重建，避免ALTER TABLE t ENGINE=InnoDB在大数据量下锁表太久 - MyISAM 的
CHECK TABLE和REPAIR TABLE命令在 SSD + 高并发下极易卡死，InnoDB 的innodb_force_recovery虽麻烦，但至少可控
聚簇索引不是“更快的索引”，它是“数据即索引”的组织方式；理解这点，才能避开把 InnoDB 当 MyISAM 用的典型误区——比如给非主键字段狂建索引，却忘了主键设计本身才是性能地基。
