InnoDB 在 WHERE + ORDER BY + LIMIT 查询中性能更优，因其聚簇索引避免回表；MyISAM 仅适合静态只读场景；Memory 引擎因数据易失、表级锁和索引限制不适用于实时统计；ROW_FORMAT=Dynamic 可提升含大字段查询的 I/O 效率；Archive 引擎不支持索引和范围查询，仅适用于冷备或主键精确查找。
MyISAM 和 InnoDB 在 WHERE 查询中的响应差异
MyISAM 表在纯读场景下可能看起来更快，是因为它不支持事务、行锁和外键约束，索引结构更轻量；但一旦有并发写入或需要 WHERE 条件配合 ORDER BY + LIMIT 分页，InnoDB 的聚簇索引优势立刻显现——数据行直接按主键物理排序，避免回表。MyISAM 的非聚簇索引需额外一次磁盘寻址取数据，高并发时容易成为瓶颈。
常见错误现象：SELECT * FROM logs WHERE status = 'pending' ORDER BY created_at DESC LIMIT 20 在 MyISAM 上执行缓慢，且随着表增长线性变差；换成 InnoDB 后即使没加复合索引，性能也更稳定。
- 若查询频繁使用
WHERE + ORDER BY + LIMIT，优先选 InnoDB，并确保ORDER BY字段在索引中位置合理 - MyISAM 仅适合静态日志归档、报表快照等极少更新的只读场景
- InnoDB 的
autocommit=1默认行为对单条查询无额外开销，不必为“怕慢”而切引擎
Memory 引擎是否真能加速实时统计查询
Memory 引擎把表完全放内存，看似理想，但它不支持 BLOB/TEXT 类型，也不支持全文索引或外键；更关键的是：所有数据在 MySQL 重启后丢失，且表级锁在高并发 INSERT/UPDATE 下极易阻塞。
使用场景有限：仅适用于临时中间结果聚合（如 CREATE TEMPORARY TABLE ... ENGINE=MEMORY），或极小维度表（如状态码映射表）缓存。拿它存用户会话或订单汇总，反而因锁争用拖慢整体查询。
- Memory 表无法使用
EXPLAIN中的key_len判断索引效率，因为其索引是哈希或 B-Tree 模拟，实际命中率难预测 - 当
SELECT COUNT(*) FROM memory_table返回不准（未刷新统计信息），别误判为“查询快” - 真正需要内存加速的，应考虑
query_cache（已弃用）或应用层缓存，而非强依赖 Memory 引擎
为什么 InnoDB 的行格式（ROW_FORMAT）会影响 SELECT 性能
ROW_FORMAT=COMPACT 是默认值，紧凑存储但字段长度变化大时易产生碎片；ROW_FORMAT=Dynamic 支持大字段溢出存储，减少主键索引膨胀，对含 TEXT 或长 VARCHAR 的查询更友好——尤其当 SELECT 只需主键和几个短字段，InnoDB 能跳过溢出页加载，显著降低 I/O。
典型问题：SELECT id, title FROM articles WHERE category_id = 5，如果 articles 表含长 content TEXT 字段且用 COMPACT 格式，即使不查 content，也可能因行碎片导致缓冲池命中率下降。
- 建表时显式指定
ROW_FORMAT=Dynamic，尤其字段含可变长文本 - 执行
ALTER TABLE t ROW_FORMAT=Dynamic不会自动整理碎片，需配合OPTIMIZE TABLE -
innodb_file_per_table=ON必须开启，否则Dynamic无法生效
Archive 引擎在历史数据归档查询中踩过的坑
Archive 引擎专为压缩存储大量历史数据设计，但它的查询能力极其受限：不支持索引（除主键伪索引）、不支持 UPDATE/DELETE、SELECT 必须全表扫描。很多人以为“存得少就查得快”，结果发现 SELECT COUNT(*) FROM archive_log WHERE date > '2023-01-01' 比 InnoDB 慢一个数量级。
它只适合两类操作：全量导出（mysqldump）或按主键精确查找（WHERE id = ?）。任何范围查询、模糊匹配、聚合统计都应提前移出 Archive 表。
- Archive 表无法用
EXPLAIN分析执行计划，type恒为ALL，别被假象误导 - 插入速度虽快，但后续查询代价被严重低估，归档前务必确认下游是否真只做冷备，而非“偶尔查一下”
- 替代方案：用分区表（
PARTITION BY RANGE）+ 压缩选项（KEY_BLOCK_SIZE），兼顾查询与空间
InnoDB 不是万能解药，但绝大多数查询性能问题根源不在“该不该换引擎”，而在索引设计是否匹配访问模式、行格式是否适配字段特征、以及是否误把存储优化当成了查询加速。引擎选型一旦定下，调整成本远高于加一条索引或改一个 ROW_FORMAT。
