mysql的索引类型和索引方法

在这里插入图片描述

前言

在 MySQL 中，索引类型和索引方法是两个不同的概念。索引类型决定了可以存储的数据种类以及索引的功能特性，而索引方法则定义了索引数据的组织方式和查找机制。
在 MySQL 中，索引（Index）是用于加快数据检索速度的数据结构。它们可以显著提高查询性能，但也可能会影响插入、更新和删除操作的性能，因为每次数据更改时索引也需要更新。

索引类型

NORMAL（普通索引）：
- 这是最常见的索引类型，它没有唯一性约束，允许重复值。
- 普通索引可以加速检索操作，但不会强制任何数据完整性规则。
- 普通索引以 ix_开头

1. 普通索引（NORMAL、INDEX 或 KEY）

在 MySQL 中，术语“普通索引”（INDEX 或 KEY）和 “NORMAL” 索引通常指的是同一种类型的索引。

普通索引（INDEX 或 KEY）：这是最基本的索引类型，它没有唯一性或其他特殊限制。创建普通索引的目的是为了加速查询速度，同时允许列中的值重复，并且可以包含空值（NULL）。在 CREATE TABLE 或 ALTER TABLE 语句中，你可以使用 INDEX 或 KEY 关键字来定义这种索引。
NORMAL（普通索引）：实际上，在 MySQL 的官方文档或 SQL 标准语法中并没有 “NORMAL” 这个术语。有时候人们可能会用 “NORMAL” 来指代普通的、非唯一的索引，以区别于其他类型的索引如唯一索引（UNIQUE）、主键（PRIMARY KEY）等。但这是非正式的说法，并不是标准的 SQL 语法的一部分。
因此，当你看到 “普通索引” 或者 “NORMAL” 索引时，它们实际上是指同一个概念：即没有任何额外约束条件的基本索引，主要用于提高查询性能。

这是最基本的索引类型，没有任何限制。它能加快查询速度，但不会强制列中的值必须唯一。

示例：

CREATE INDEX idx_lastname ON employees (lastname);

CREATE 索引名 自定义索引名 ON 表名 (列名);

-- 创建表时添加普通索引
CREATE TABLE employees (
    id INT NOT NULL,
    lastname VARCHAR(50),
    INDEX idx_lastname (lastname)
);

-- 或者使用 KEY 关键字
CREATE TABLE employees (
    id INT NOT NULL,
    lastname VARCHAR(50),
    KEY idx_lastname (lastname)
);

-- 对现有表添加普通索引
ALTER TABLE employees ADD INDEX idx_lastname (lastname);

2. 唯一索引（UNIQUE INDEX 或 UNIQUE KEY）

除了提供快速查找功能外，唯一索引还保证了数据表中每一行记录在这个索引上的值都是唯一的。允许有一个空值（NULL）存在。
确保索引列中的所有值都是唯一的，除了 NULL 值外（NULL 被认为是相等的）。
有助于保持数据的完整性，常用于主键或确保某列不包含重复值。
唯一键以uk_ 开头

示例：

CREATE UNIQUE INDEX uk_email ON employees (email);

CREATE UNIQUE KEY uk_email ON employees (email);

CREATE 索引名 自定义索引名 ON 表名 (列名);

3. 主键（PRIMARY KEY）

主键是一种特殊的唯一索引，不允许有空值（NULL）。一个表只能有一个主键，并且主键自动创建一个聚集索引（如果该表没有其他聚集索引的话）。

示例：

ALTER TABLE employees ADD PRIMARY KEY (id);

使用 ALTER TABLE 语句为现有的表添加主键约束是常见的数据库管理操作。
命令：

ALTER TABLE employees ADD PRIMARY KEY (id);

这条 SQL 语句的作用是将 employees 表的 id 列设置为主键。这不仅会创建一个唯一索引以确保该列中的所有值都是唯一的，而且还会保证该列不允许有空值（NULL）。此外，如果表中没有聚集索引，那么这个主键也会成为表的聚集索引。

注意事项

唯一性检查：在执行此命令之前，MySQL 会检查 id 列中的所有现有数据，确保它们是唯一的并且没有空值。如果有任何违反这些条件的数据存在，命令将会失败，并返回错误信息。
数据类型和索引：通常，主键应该是一个整数类型（如 INT），并且最好是自增（AUTO_INCREMENT）的，以便每次插入新记录时自动产生唯一的标识符。
性能影响：添加主键会创建索引，这对查询性能有正面影响，但可能会影响插入、更新和删除操作的速度，因为每次这些操作发生时都需要维护索引。
已存在的主键：如果你试图在一个已经有主键的表上再次添加主键，MySQL 将抛出错误。每个表只能有一个主键。
外键依赖：如果其他表中有外键引用了 employees 表的 id 列，那么在添加主键时需要考虑这些依赖关系，确保不会破坏数据库的完整性。

示例

假设你有一个名为 employees 的表，且该表的 id 列已经包含了唯一且非空的值，你可以通过如下命令添加主键：

ALTER TABLE employees ADD PRIMARY KEY (id);

如果 id 列不是自增的，并且你希望它在未来的插入操作中自动增加，可以在创建表时定义它为 AUTO_INCREMENT，或者对于某些存储引擎，在表已经存在的情况下，也可以通过修改列定义来实现这一点：

ALTER TABLE employees MODIFY id INT AUTO_INCREMENT;

然后你可以添加主键：

ALTER TABLE employees ADD PRIMARY KEY (id);

请确保在执行这些更改前备份你的数据，以防出现意外情况。如果你不确定当前表结构或数据状态，可以先运行 DESCRIBE employees; 或 SHOW CREATE TABLE employees; 来查看当前表的定义。

4. 全文索引（FULLTEXT INDEX）

全文索引专门用于文本搜索，适用于 CHAR、VARCHAR 和 TEXT 类型的列。它可以进行复杂的模式匹配查询，如全文搜索。
用于全文搜索，特别适用于大文本字段（如 TEXT、CHAR 和 VARCHAR）。
支持自然语言模式、布尔模式和查询扩展模式的搜索。
只能在 MyISAM 和 InnoDB 存储引擎上的表中使用。

示例：

CREATE FULLTEXT INDEX ft_description ON articles (description);

CREATE 索引名 自定义索引名 ON 表名 (列名);

5. 组合索引（Composite Index）

组合索引是指在一个索引中包含多个列。MySQL 使用最左前缀原则来匹配组合索引，这意味着查询条件中最左边的列需要出现在 WHERE 子句中以利用索引。

示例：

CREATE INDEX idx_name_salary ON employees (firstname, salary);

CREATE 索引名 自定义索引名 ON 表名 (列名,列名);

6. 空间索引（SPATIAL INDEX）

空间索引是为存储几何对象而设计的索引，通常用于地理信息系统（GIS）应用。仅支持 MyISAM 表，并且列不能包含空值。
专门用于空间数据类型的索引，例如 GEOMETRY 类型。
要求列中的所有值都是非空的，并且只能应用于 MyISAM 表（直到 MySQL 5.7 版本），从 MySQL 8.0 开始支持 InnoDB 表。

示例：

CREATE SPATIAL INDEX sp_index ON geom_table (geom_column);

CREATE 索引名 自定义索引名 ON 表名 (列名);

7. 聚簇索引（Clustered Index）

聚簇索引决定了数据在表中的物理存储顺序。每个表最多只能有一个聚簇索引。当您定义主键时，MySQL 默认会创建聚簇索引（除非表已经有一个聚簇索引）。
聚簇索引（Clustered Index）是数据库中一种特殊的索引类型，它决定了表中数据的物理存储顺序。在 MySQL 中，每个表最多只能有一个聚簇索引，因为数据行本身只能按照一种方式排序和存储。理解聚簇索引对于优化查询性能非常重要。

特性

数据存储：聚簇索引将数据行与索引项一起存储。这意味着当您通过聚簇索引查找数据时，找到索引项也就意味着找到了数据本身，无需再进行额外的查找操作。
唯一性：虽然聚簇索引不要求键值必须唯一，但如果不是唯一的，MySQL 会自动为非唯一键值添加一个隐藏列来确保每一行都是唯一的。这通常发生在 InnoDB 存储引擎中，其中主键通常是聚簇索引。
排序顺序：表中的数据按照聚簇索引的键值排序存储。如果表有多个索引，只有一个是聚簇索引，其他都是非聚簇索引（也称为二级索引或辅助索引）。
性能优势：
- 对于范围查询（如 BETWEEN、>、< 等），聚簇索引通常比非聚簇索引更高效，因为它可以连续读取相关数据。
- 当检索大量数据时，聚簇索引可以减少I/O操作次数，因为数据已经按索引顺序排列。
插入性能：由于数据是按聚簇索引键值排序的，频繁插入新记录可能导致页分裂（page splits），特别是在聚簇索引不是递增的情况下，这可能会影响性能。
更新影响：更改聚簇索引键值可能会导致行被移动到新的位置，从而引发页重组，这同样可能降低性能。
默认创建：在 InnoDB 表中，如果您定义了一个主键，那么该主键就是聚簇索引。如果没有显式定义主键，InnoDB 会选择第一个唯一且非空的索引作为聚簇索引；如果没有这样的索引，InnoDB 将创建一个隐式的聚簇索引。

创建聚簇索引

最常见的方式是在创建表时定义一个主键，因为主键默认是聚簇索引。例如：

Sql深色版本

CREATE TABLE employees (
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    PRIMARY KEY (id)
) ENGINE=InnoDB;

在这个例子中，id 列是主键，因此也是聚簇索引。

如果你想在现有表上创建聚簇索引，并且该表还没有主键，你可以通过以下方式添加一个主键：

Sql深色版本

ALTER TABLE employees ADD PRIMARY KEY (id);

请注意，一旦选择了聚簇索引，就很难改变它，因为这涉及到重新组织整个表的数据。因此，在设计表结构时应慎重考虑哪个列适合作为聚簇索引。

聚簇索引 vs 非聚簇索引

聚簇索引：数据按索引键值排序存储，适合范围查询，但不适合频繁更新或插入非递增值。
非聚clus索引（Secondary Indexes）：包含指向实际数据行的指针，不决定数据的物理存储顺序。它们更适合用于等值匹配查询，但在范围查询上不如聚簇索引有效。

选择合适的索引类型取决于你的应用程序需求和访问模式。正确使用聚簇索引可以显著提高查询性能，但也需要权衡对写入操作的影响。

8. 非聚簇索引（Non-Clustered Index）

非聚簇索引不决定表中数据的物理存储顺序。相反，它们是在表之外创建的结构，其中包含指向实际数据行的指针。
非聚簇索引（Non-Clustered Index），也称为二级索引或辅助索引，在数据库中用于加速数据检索而不改变表中数据的物理存储顺序。与聚簇索引不同，每个表可以拥有多个非聚簇索引，这使得它们非常适合多维度查询优化。

特性

独立于数据存储：非聚簇索引不决定表中数据的物理存储顺序。它们是独立的数据结构，通常以B树的形式存在，包含索引列的值和指向实际数据行的指针（对于InnoDB存储引擎）或行标识符（对于MyISAM存储引擎）。
支持多索引：由于非聚簇索引不影响数据的物理存储，因此可以在同一个表上创建多个非聚簇索引，以优化不同类型的查询。
覆盖索引：如果一个非聚簇索引包含了查询所需的所有列，则称其为覆盖索引（Covering Index）。在这种情况下，MySQL可以直接从索引中获取所有信息，而无需访问表本身，从而提高查询效率。
查找过程：
- 查询首先在非聚簇索引中进行查找，找到匹配的索引项。
- 然后根据索引项中的指针或行标识符定位到实际的数据行。
- 对于频繁使用的查询路径，使用非聚簇索引可以显著减少I/O操作次数。
维护成本：每当表中的数据发生插入、更新或删除操作时，相关的非聚簇索引也需要同步更新，这可能会增加写入操作的成本。
适合场景：
- 非聚簇索引特别适合用于等值匹配查询（如 = 操作符）和某些范围查询。
- 它们对于经常执行的查询特别有用，即使这些查询只涉及表的一小部分列。
性能考虑：
- 创建过多的非聚簇索引会增加写入操作的时间，并占用额外的磁盘空间。
- 不恰当的索引选择可能导致索引未被使用，反而增加了系统的负担。

创建非聚簇索引

在 MySQL 中，可以通过 CREATE INDEX 或 ALTER TABLE 语句来创建非聚簇索引。例如：

-- 创建表时添加非聚簇索引
CREATE TABLE employees (
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    department_id INT,
    INDEX idx_department (department_id)
) ENGINE=InnoDB;

-- 对现有表添加非聚簇索引
ALTER TABLE employees ADD INDEX idx_department (department_id);

或者更简洁地使用 CREATE INDEX 语句：

CREATE INDEX idx_department ON employees (department_id);

在这个例子中，idx_department 是一个非聚簇索引，它将加速基于 department_id 的查询，但不会影响 employees 表中数据的实际存储顺序。

聚簇索引 vs 非聚簇索引

特性	聚簇索引（Clustered Index）	非聚簇索引（Non-Clustered Index）
数据存储	决定表中数据的物理存储顺序	独立于数据存储，包含指向实际数据行的指针
唯一性	必须唯一	可以不是唯一的
数量限制	每个表只能有一个	每个表可以有多个
查找效率	对于范围查询特别高效	对于等值匹配查询特别高效
插入/更新成本	插入非递增值或更新键值可能引发页分裂	每次表数据更改时需要更新相关索引
覆盖索引	自动覆盖主键查询	可以通过精心设计成为覆盖索引

正确选择和使用非聚簇索引可以极大地提高查询性能，但同时也需要考虑到维护这些索引所带来的额外开销。在设计数据库时，应该根据应用的具体需求来权衡索引的数量和类型。

9. 覆盖索引（Covering Index）

如果一个索引包含了查询所需的所有列，则称其为覆盖索引。在这种情况下，MySQL 可以直接从索引中获取所有信息，而无需访问表本身，这可以极大地提高查询效率。
在 MySQL 中，覆盖索引（Covering Index） 是一种优化技术，它指的是一个索引包含了查询所需的所有列，使得数据库引擎可以直接从索引中获取所有需要的数据，而无需访问表中的实际数据行。这可以显著减少磁盘I/O操作和处理时间，从而提升查询性能。

工作原理

当 MySQL 执行查询时，如果查询的条件和返回的列都在同一个索引中，MySQL 就不需要回表查找实际的数据行，而是直接从索引中读取数据。这种情况下，该索引就被称为覆盖索引。

创建覆盖索引

要创建覆盖索引，通常会创建一个多列索引，这些列不仅包括查询条件中涉及的列，还包括查询结果集中需要的其他列。例如：

CREATE INDEX idx_covering ON employees (department_id, name, salary);

在这个例子中，idx_covering 索引覆盖了 department_id、name 和 salary 列。
对于如下查询：

SELECT name, salary FROM employees WHERE department_id = 10;

由于查询条件 WHERE department_id = 10 和查询结果集 SELECT name, salary 中的所有列都包含在 idx_covering 索引中，因此这个索引就是覆盖索引，MySQL 可以直接从索引中获取所需的数据，而不需要访问 employees 表本身。

示例

假设有一个名为 orders 的表，结构如下：

CREATE TABLE orders (
    order_id INT NOT NULL,
    customer_id INT NOT NULL,
    order_date DATE NOT NULL,
    total_amount DECIMAL(10,2) NOT NULL,
    PRIMARY KEY (order_id)
);

如果我们经常执行如下查询：

SELECT order_date, total_amount FROM orders WHERE customer_id = 12345;

为了优化这个查询，我们可以创建一个覆盖索引：

CREATE INDEX idx_customer_order ON orders (customer_id, order_date, total_amount);

现在，对于上述查询，MySQL 可以完全依赖于 idx_customer_order 索引来获取所需的数据，而不需要访问 orders 表的实际数据行。

注意事项

选择合适的列：创建覆盖索引时应仔细选择哪些列应该包含在索引中。过多的列会增加索引的大小，进而影响写入性能和存储成本。
维护成本：每次对表进行插入、更新或删除操作时，覆盖索引也需要同步更新，这可能会增加写入操作的成本。因此，在设计索引时需要权衡读取与写入性能之间的关系。
组合索引：通常，覆盖索引是多列索引的一部分。合理的组合索引不仅可以作为覆盖索引使用，还可以提高其他类型查询的性能。
分析查询模式：了解应用程序的查询模式非常重要，因为并不是所有的查询都可以通过相同的覆盖索引来优化。应该根据最频繁使用的查询来设计覆盖索引。
检查是否使用了索引：可以通过 EXPLAIN 或 EXPLAIN ANALYZE（取决于 MySQL 版本）命令来查看查询执行计划，确认查询是否真的使用了预期的覆盖索引。

总之，合理地利用覆盖索引可以显著提高查询性能，尤其是在大型数据集上。
但是，创建索引时应当谨慎考虑其带来的额外开销，并确保索引的设计符合实际应用的需求。

10. 哈希索引（Hash Index）

哈希索引主要用于内存中的临时表（MEMORY 存储引擎）。它们非常适合等值比较查询，但在范围查询或排序方面表现不佳。
哈希索引（Hash Index）是 MySQL 中一种特殊的索引类型，主要用于快速查找等值匹配的查询。它通过使用哈希函数将键值映射到特定位置，从而实现高效的查找操作。哈希索引特别适用于 = 和 IN 操作符的查询条件，但在范围查询和排序方面表现不佳。在 MySQL 中，哈希索引主要应用于内存表（MEMORY 存储引擎）以及 InnoDB 的自适应哈希索引。

特性

快速等值查找：对于等值匹配查询（如 WHERE column = value），哈希索引能够提供非常快的查找速度，因为它可以直接定位到记录的位置。
不支持范围查询：哈希索引不适合用于范围查询（如 BETWEEN、>、< 等），因为哈希函数打乱了数据的顺序，无法利用相邻关系来加速范围查找。
不支持部分匹配：哈希索引也不适合用于部分匹配查询（如 LIKE 'pattern%'），因为哈希值是根据整个键值计算的，而不是基于键的一部分。
处理冲突：由于哈希函数可能会产生冲突（即不同的键值可能得到相同的哈希值），哈希索引通常需要额外的机制来处理这种情况，例如链地址法或开放寻址法。
存储结构：哈希索引通常以哈希表的形式存储，每个哈希值对应一个桶（bucket），桶中可以包含多个记录指针。
内存优化：哈希索引非常适合内存中的临时表（MEMORY 存储引擎），因为它们可以在内存中高效地工作，减少磁盘I/O。
InnoDB 自适应哈希索引：InnoDB 存储引擎有一个特性叫做自适应哈希索引（Adaptive Hash Index, AHI），它会自动根据查询模式创建哈希索引来加速访问。这个功能可以根据实际查询情况动态调整，但也可以通过配置禁用。

使用场景

高频率的等值查找：如果应用程序中有大量的等值查找操作，哈希索引可以显著提高这些查询的性能。
内存表：对于那些完全驻留在内存中的表（如 MEMORY 存储引擎），哈希索引可以提供极高的查找速度。
缓存层：有时哈希索引被用来构建应用级别的缓存层，以加速频繁访问的数据。

创建哈希索引

在 MySQL 中，哈希索引通常与 MEMORY 存储引擎一起使用。要为 MEMORY 表创建哈希索引，可以使用 CREATE TABLE 或 ALTER TABLE 语句，并指定 USING HASH 关键字：

-- 创建表时添加哈希索引
CREATE TABLE lookup (
    id INT NOT NULL,
    data VARCHAR(50),
    INDEX idx_hash USING HASH (id)
) ENGINE=MEMORY;

-- 对现有表添加哈希索引
ALTER TABLE lookup ADD INDEX idx_hash USING HASH (id);

请注意，只有 MEMORY 存储引擎默认支持显式创建哈希索引。其他存储引擎如 InnoDB 和 MyISAM 默认使用 B-tree 类型的索引。

注意事项

适用性有限：由于哈希索引只适用于等值匹配查询，因此在选择哈希索引时应确保它符合查询模式。
数据分布：哈希索引的效果依赖于键值的良好分布。如果数据分布不均匀，可能会导致某些桶过载，进而影响性能。
维护成本：尽管哈希索引查找速度快，但在插入、更新或删除操作时，哈希索引也需要进行相应的维护，这可能会增加写入操作的成本。
InnoDB 自适应哈希索引：虽然 InnoDB 支持自适应哈希索引，但这不是用户直接控制的索引类型，而是由存储引擎根据访问模式动态创建和管理的。

总之，哈希索引是一种高度专门化的索引类型，适用于特定类型的查询。正确理解其工作原理和限制可以帮助你在适当的情况下利用它来优化数据库性能。

总结

选择合适的索引类型对于优化数据库性能非常重要。不同的索引适用于不同的场景，因此了解你的应用程序需求和数据访问模式可以帮助你做出正确的选择。此外，创建过多的索引可能会导致写入操作变慢，因此应该权衡读取与写入性能之间的关系。

索引方法

BTREE（B-Tree）：
- 大多数情况下默认使用的索引方法。
- B-Tree 索引非常适合范围查询（如 >、<、BETWEEN）、精确匹配查询和排序操作。
- 支持前缀匹配（即部分字符串匹配）。
- InnoDB 和 MyISAM 存储引擎都支持 B-Tree 索引。
HASH：
- HASH 索引主要用于精确匹配查询，而不是范围查询。
- 它们通过哈希函数将键转换为哈希值来实现快速查找。
- HASH 索引对等值查询非常有效，但在执行范围查询时效率不高。
- MEMORY (HEAP) 表存储引擎支持 HASH 索引；InnoDB 引擎也提供了一种特殊的自适应哈希索引功能，该功能根据查询模式自动创建哈希索引以加速某些类型的查询。

索引-检查规则

索引名-长度不超过32个字符
不能使用保留字索引名-全小写索引名-英文及下划线
索引名-主键的名称以pk 开头，唯一键以uk_ 开头，普通索引以 ix_开头

MySQL 索引设计和使用的关键规范

1. 选择合适的索引类型

聚簇索引（Clustered Index）：通常为主键，每张表只能有一个。它决定了数据的物理存储顺序。
非聚簇索引（Non-Clustered Index）：可以有多个，适合加速不同类型的查询。
唯一索引（Unique Index）：确保列中的值是唯一的。
全文索引（Full-Text Index）：用于文本搜索，适用于 CHAR、VARCHAR 和 TEXT 类型的列。
哈希索引（Hash Index）：主要用于内存表（MEMORY 存储引擎），适用于等值查找。

2. 合理选择索引列

选择性高的列：选择性是指不同值的数量与总行数的比例。选择性越高，索引的效果越好。
常用查询条件：优先为经常出现在 WHERE 子句中的列创建索引。
排序和分组列：如果查询中经常使用 ORDER BY 或 GROUP BY，考虑为这些列创建索引。
覆盖索引：尽量创建包含查询所需所有列的多列索引，以实现覆盖索引，减少回表查找。

3. 避免过度索引

权衡读写性能：虽然索引可以加快读取速度，但会增加写入操作（如插入、更新、删除）的成本，因为每次都需要维护索引。
评估索引效益：定期分析查询日志，确定哪些索引真正提高了性能，去除不使用的或低效的索引。

4. 正确使用组合索引

最左前缀原则：MySQL 使用最左前缀匹配来利用组合索引。因此，在定义组合索引时，应将选择性最高的列放在最左边。
避免冗余索引：不要创建包含已有索引子集的新索引，例如已经有了 (col1, col2) 的索引，则不需要再单独创建 (col1) 的索引。

5. 保持索引更新

定期重建索引：随着数据的变化，索引可能会变得碎片化，影响性能。可以通过 ALTER TABLE ... REBUILD 或 OPTIMIZE TABLE 来重建索引。
监控索引使用情况：使用 EXPLAIN 或 EXPLAIN ANALYZE 查看查询执行计划，确认是否使用了预期的索引。