BTREE 在 MySQL 中的好处

Question

BTREE在查询速度、磁盘存储和内存使用方面，在 MySQL中使用索引的优缺点是什么？

• 是否BTREE按递增顺序提供更简单的迭代？
• 什么样的查询会从 a 中受益BTREE？
• 使用BTREEindex有什么缺点吗？
• 它会增加空间或索引时间吗？

Answer 1

无论存储引擎（MyISAM 还是 InnoDB），当涉及到BTREEs 时，您必须确保您了解以下特性：

• 键应该尽可能小
• PRIMARY KEY 的随机密钥
  • 插入（批量或程序化）将定期执行根节点和内部分裂
  • 在索引生命周期的早期引入开销
  • 滋生节点碎片（尤其是索引页）
  • 导致随机执行查询的索引扫描
• PRIMARY KEY 的有序键
  • 批量有序插入延迟根节点和内部分裂
  • 通过mysqldump文件和LOAD DATA INFILE命令重新加载数据促进了使用排序机制来解决索引初始化/重组（请参阅我在 2012 年 10 月 26 日发表的帖子：innodb 片段在遇到一些乱序插入时有多糟糕？）
  • 程序化有序插入在 45% 的情况下促进了根节点和索引页的内部拆分
  • 延迟创建开销
  • 防止节点碎片
  • 导致按顺序执行查询的索引扫描（减少磁盘 I/O）

当谈到 InnoDB 中的BTREE 时，由于 InnoDB 的gen_clust_index，它们往往比其对应的 MyISAM 更加臃肿，行数据所在的位置。

InnoDB 表的 PRIMARY KEY 直接指向其 gen_clust_index。二级索引总是包含一个 PRIMARY KEY 条目。如果您运行的查询使用二级索引并且在 WHERE 子句中也有非索引列，您可以轻松地进行两次索引查找。考虑到这一点，您需要确保所有二级索引都具有查询的 WHERE 子句（又名Covering Index）所需的所有列。

Answer 2

相比之下有什么优点和缺点？从文档中：

索引类型

某些存储引擎允许您在创建索引时指定索引类型。不同存储引擎支持的允许索引类型值如下表所示。如果列出了多个索引类型，则在未给出索引类型说明符时，第一个索引类型为默认值。

Storage Engine   Permissible Index Types
----------------------------------------
MyISAM           BTREE
InnoDB           BTREE
MEMORY/HEAP      HASH, BTREE
NDB              HASH, BTREE

index_type 子句不能与 SPATIAL INDEX 一起使用。