当前表引擎可通过show create table table_name查看engine=值，或查information_schema.tables；myisam无事务日志，崩溃后数据不一致且修复不可靠，innodb依赖redo/undo log保证崩溃恢复；myisam缓存行数使count(*)快但不准，innodb每次扫描聚簇索引但结果可靠；innodb行锁需索引精准匹配，否则退化为表锁；myisam适合只读静态表，其余场景默认选innodb。
怎么查当前表用的是哪个引擎
执行 SHOW CREATE TABLE table_name，看输出里 ENGINE=InnoDB 还是 ENGINE=MyISAM；或者直接查系统表：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table'。别只看 MySQL 版本默认值——5.5 之后默认是 InnoDB，但老库迁移或手动建表时可能混着用，不确认就容易踩坑。
事务和崩溃恢复能力差在哪
MyISAM 没有事务日志，INSERT 或 UPDATE 中断（比如断电、kill -9）后，数据文件可能处于中间状态：部分写入、索引与数据不一致，必须靠 myisamchk 修复，且无法保证修复后逻辑正确。InnoDB 依赖 redo log 和 undo log，重启后自动前滚/回滚，只要磁盘没坏，一定能回到某个已提交事务的一致点。如果你的业务涉及支付、订单、账户余额，选 MyISAM 就等于主动放弃数据安全底线。
为什么 count(*) 在 MyISAM 快、InnoDB 慢
MyISAM 在内存里缓存了精确行数，SELECT COUNT(*) FROM t 直接返回；InnoDB 每次都得扫聚簇索引（哪怕加了 WHERE 1=0 也绕不开）。但注意：这个“快”只对无条件全表统计成立。一旦加了 WHERE，两者都要走索引或全表扫描，MyISAM 并不占优。更关键的是——MyISAM 的行数在并发 INSERT/DELETE 时可能不准（尤其用了 CONCURRENT INSERT），而 InnoDB 虽慢但结果绝对可靠。
行锁不是万能的，InnoDB 也会锁整张表
InnoDB 只有通过**索引条件**精准定位行时才用行锁；如果 WHERE 条件没走索引（比如 LIKE '%abc'、字段类型隐式转换）、或优化器判断范围太大，它会退化为表级锁。而 MyISAM 不管什么条件，读写一律锁整表。所以别光看“支持行锁”就放心——得配好索引、写对 SQL，否则并发写照样堵死。另外，MyISAM 的 AUTO_INCREMENT 允许非首列组合索引，InnoDB 要求自增列必须是索引最左列，改表结构时容易报错。
真正做选型时，别纠结“读多写少”这种模糊说法——得看“写是否涉及强一致性”“是否允许修复中断”“是否需要外键约束”。MyISAM 现在基本只适合静态报表表、归档只读表，或者极小项目里图省事。其余情况，默认选 InnoDB，除非你明确知道它不支持的特性（比如旧版全文索引）对你不可替代。
