mysql中使用位图索引与哈希索引的性能比较

MySQL原生不支持位图索引，InnoDB和MyISAM均无BITMAP索引类型；仅Memory引擎支持显式哈希索引，InnoDB的自适应哈希索引为隐式且不可控。

MySQL 原生不支持位图索引（Bitmap Index）和哈希索引（Hash Index）作为通用存储引擎的常规索引类型——这是关键前提，直接决定后续所有性能比较是否成立。

MySQL 有没有位图索引？

没有。位图索引常见于 OLAP 场景的列式数据库（如 Oracle、Greenplum、ClickHouse 的某些实现），但 InnoDB 和 MyISAM 均不提供 BITMAP 索引类型。即使你执行 CREATE INDEX idx ON t(col) USING BITMAP，MySQL 会报错：ERROR 1064 (42000): Syntax error near 'BITMAP'。

如果你在 MySQL 中看到“位图”相关行为，大概率是以下情况之一：

• 应用层用 BLOB 或 VARBINARY 手动维护位图结构（极少见，且需自行处理并发与一致性）
• 误将 SET 或 ENUM 类型的内部存储机制理解为位图索引（实际仍是 B+ 树索引）
• 使用了 MySQL NDB Cluster（已基本淘汰），它支持位图索引，但仅限于 NDB 引擎，且不适用于主流 OLTP 场景

MySQL 支持哈希索引吗？

仅在 Memory 引擎中支持显式哈希索引；InnoDB 的自适应哈希索引（adaptive_hash_index）是隐式、只读、自动管理的，无法由用户创建或控制。

Memory 引擎的哈希索引使用方式：

CREATE TABLE t_mem (
  id INT,
  name VARCHAR(32)
) ENGINE=MEMORY;
CREATE INDEX idx_name ON t_mem(name) USING HASH;

注意：

• 哈希索引只支持 = 和 等精确匹配，不支持范围查询（>、BETWEEN）、LIKE 'prefix%' 或排序（ORDER BY）
• 哈希冲突会导致链表退化，高重复值下性能急剧下降（例如对全为 'N/A' 的 status 列建哈希索引）
• Memory 表数据不持久，重启即丢，仅适合临时缓存类场景

为什么不能拿 InnoDB 的 B+ 树索引和“假想的位图/哈希索引”比性能？

因为对比对象不存在。真实可选的索引类型只有：

• InnoDB：仅支持 BTREE（默认），语法上虽允许 USING HASH，但会被静默忽略，仍建 B+ 树
• MyISAM：仅支持 BTREE
• Memory：支持 HASH 和 BTREE，但适用场景受限

若真要优化等值查询性能，应优先考虑：

• 联合索引最左前缀匹配（INDEX(a,b) 能加速 WHERE a = ? AND b = ?）
• 覆盖索引避免回表（SELECT id FROM t WHERE status = 'done' + INDEX(status, id)）
• 适当压缩索引（KEY_BLOCK_SIZE 对大字段有效）
• 确认 adaptive_hash_index 是否开启（SHOW VARIABLES LIKE 'innodb_adaptive_hash_index'），它会在热点 B+ 树页上自动构建哈希映射，加速重复等值查询

真正需要位图或哈希语义时，得换数据库——比如高频低基数等值过滤（性别、状态码）且写少读多，ClickHouse 的 LowCardinality + 自动位图优化更合适；而超低延迟单键查找，Redis 的哈希表才是正解。在 MySQL 里硬套这两个概念，只会浪费调试时间。