InnoDB是MySQL索引优化的默认起点，因其聚簇索引决定物理存储、二级索引包含主键值，显著影响覆盖索引、范围查询与排序效率；MyISAM等引擎因缺乏事务、并发写入阻塞等问题不适用于现代业务。
为什么 InnoDB 是 MySQL 索引优化的默认起点
绝大多数需要索引优化的场景，InnoDB 不是“可选项”，而是事实上的起点。它支持行级锁、事务、外键，更重要的是——它的主键索引（聚簇索引）直接决定数据物理存储顺序，二级索引也包含主键值，这对覆盖索引、范围查询、排序效率有根本性影响。
常见误判是看到 MyISAM 的“全文索引快”或“COUNT(*) 快”就考虑切换，但这些优势在现代业务中往往被事务缺失、并发写入阻塞、崩溃恢复不可靠等问题抵消。除非你明确在做只读日志归档且无并发更新，否则别碰 MyISAM。
-
InnoDB的PRIMARY KEY必须存在，且最好为自增整型；缺失主键时会隐式创建隐藏列，导致二级索引变大、JOIN 变慢 - 复合索引顺序必须匹配查询条件最左前缀，比如
INDEX (a, b, c)能加速WHERE a=1 AND b>5，但对WHERE b=2无效 -
TEXT/VARCHAR列建索引需指定前缀长度（如INDEX (content(100))），否则可能触发ERROR 1071 (42000): Specified key was too long
什么时候该考虑 TokuDB 或 RocksDB（仅限特定场景）
如果你的表持续写入、更新频繁、且单表超千万行，同时 InnoDB 出现明显写放大或长事务卡顿，才值得评估 TokuDB（Percona Server）或 RocksDB（MySQL 8.0+ via MyRocks 插件）。它们用 LSM-tree 替代 B+tree，在高吞吐写入和压缩比上有优势，但代价是读延迟略高、内存占用更敏感、运维复杂度陡增。
-
TokuDB对ALTER TABLE ... ADD INDEX是在线的，而InnoDB在 5.6+ 虽支持ALGORITHM=INPLACE，但加唯一索引仍可能锁表 -
RocksDB的compaction过程可能在高峰期争抢 I/O，需调优rocksdb_max_background_compactions和rocksdb_rate_limiter_bytes_per_sec - 二者都不支持
FULLTEXT索引，也不兼容XA事务，若业务依赖这些特性，直接排除
如何验证当前索引是否真的生效
别信 EXPLAIN 输出里的 type: ref 就等于高效，重点看 key 是否命中预期索引、rows 是否远小于表总行数、Extra 是否出现 Using filesort 或 Using temporary。
更可靠的方式是开启慢查询日志并捕获真实执行计划：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.1; SET GLOBAL log_queries_not_using_indexes = ON;
然后查 mysql.slow_log 或对应文件，过滤出带 Rows_examined 明显偏高的语句。特别注意：如果 Rows_examined ≈ Rows_sent，说明索引基本没起作用，只是全表扫描后过滤。
- 使用
SELECT * FROM t WHERE a = ? ORDER BY b时，INDEX (a, b)比INDEX (a)+INDEX (b)更有效，后者大概率触发Using filesort -
WHERE a IN (1,2,3) AND b > 10这类混合查询，INDEX (a, b)仍能利用a的等值部分，但b的范围部分无法用于后续字段；若改成WHERE a = 1 AND b > 10，则整个索引都可用
唯一容易被忽略的细节：索引统计信息过期
InnoDB 默认每 8 次修改或 1/16 表数据变更时自动采样更新统计信息，但大表或低频更新表极易滞后。这会导致优化器选错索引，例如本该走 INDEX (status, created_at) 却走了 PRIMARY KEY。
手动更新方式有两种：
- 强制刷新：执行
ANALYZE TABLE orders;（注意：会短暂锁表，建议在低峰执行） - 长期控制：调整
innodb_stats_auto_recalc = ON并设innodb_stats_persistent = ON，再配合定期UPDATE STATISTICS任务 - 调试阶段可临时关闭自动更新：
SET GLOBAL innodb_stats_auto_recalc = OFF;，避免干扰测试结果
真正棘手的是统计信息“看起来准、实际不准”——比如某字段值高度倾斜（99% 是 'active'），优化器仍按均匀分布估算，这时只能靠 FORCE INDEX 或重写查询逻辑绕过。
