EXPLAIN中key为NULL说明未使用索引，因B+Tree不支持LIKE '%abc'左模糊匹配，属物理限制，与引擎无关。
EXPLAIN 看不到 key 就说明没走索引
执行 EXPLAIN SELECT * FROM t WHERE name LIKE '%abc'，如果结果中 key 列为 NULL，代表 InnoDB 和 MyISAM 都没用上索引——哪怕 name 上建了 B+Tree 索引。这不是配置问题，是 B+Tree 本身无法支持左模糊匹配（%abc）的物理限制。MyISAM “看起来快”往往只是因为没开事务、没 MVCC、没行锁开销，直接读磁盘页；但一旦并发写入增多，这种“快”会立刻崩塌。
LIKE 'abc%' 在两种引擎下都可能走索引
只要模式是右模糊（LIKE 'abc%'），且字段没被函数包裹、类型匹配、没 ESCAPE 错误，InnoDB 和 MyISAM 都能利用 B+Tree 的前缀特性快速定位起始位置。此时 EXPLAIN 中 key 字段会显示索引名，type 通常是 range。但注意：InnoDB 因聚簇索引特性，若查询需回表取非索引字段，实际 I/O 可能略高于 MyISAM（后者索引只存地址，跳转更轻量）。
FULLTEXT 索引只在 MyISAM 和 InnoDB 5.6+ 有效，但行为不同
MyISAM 原生支持 FULLTEXT，且对短词（如 2 字中文、单字母）容忍度稍高；InnoDB 的 FULLTEXT 从 5.6 开始支持，但默认最小词长为 4，ft_min_word_len 修改后需重建索引，且不支持纯数字或拼音缩写类模糊匹配。两者都不支持 LIKE 语法，必须改用 MATCH ... AGAINST。例如：MATCH(title) AGAINST('database' IN NATURAL LANGUAGE MODE)。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
真正影响性能的不是引擎，而是查询是否触发 filesort 或全表扫描
当语句带 ORDER BY + LIMIT 时，比如 SELECT * FROM article WHERE content LIKE '%bug%' ORDER BY created_at DESC LIMIT 20，即使加了 FULLTEXT，ORDER BY 仍大概率触发 Using filesort——因为全文索引不维护时间顺序。此时 InnoDB 的缓冲池优势反而被拖累，而 MyISAM 没有 buffer pool，反而更“直给”。解决办法不是换引擎，而是加覆盖索引：ALTER TABLE article ADD INDEX idx_content_time (content(100), created_at)，但该索引对 LIKE '%bug%' 依然无效，只对 LIKE 'bug%' 有效。
别在 LIKE '%xxx' 场景下纠结引擎选型，B+Tree 天然不支持。该上 Elasticsearch 就上，该加反向字段就加，该切业务逻辑就切——引擎只是执行层，不是魔法棒。
