MySQL建索引你所不知道的二三事

奔跑的毛球2024-02-06 13:47

在 MySQL 中建立索引是提高查询性能的重要手段之一。一个正确的索引能大大提高查询效率，但是若是加了一个不恰当的索引，不但不能增加效率，反而因为要维护索引，反而影响了性能。所以我们在增加索引的时候一定要根据实际的情况多加考虑，慎之又慎。

以下是建立索引时需要遵循的一些原则：

  1. 选择合适的列
  2. 唯一性原则
  3. 考虑多列索引
  4. 避免在小表上建立索引
  5. 使用前缀索引
  6. 避免在频繁更新的列上建立索引
  7. 分析查询语句和执行计划
  8. 定期维护索引
  9. 监控数据库性能
  10. 使用适当的存储引擎

接下来细细每一项说说：

1.选择合适的列

选择经常用于查询条件、连接条件和排序的列进行索引。不是所有的列都适合建立索引，因为过多的索引可能导致性能下降。

在数据库中，创建索引是为了提高查询性能，但选择合适的列建立索引是至关重要的。以下是一个例子，说明为什么要选择合适的列建立索引：

假设我们有一个订单表 orders，包含以下几个字段：order_id（主键）、customer_id、order_date、total_amount。

问题场景：

现在，我们经常需要根据客户ID（customer_id）来查询该客户的订单信息。那么，我们是否应该在 customer_id 列上建立索引呢？

不合适的选择：

sql 复制代码 
CREATE INDEX idx_total_amount ON orders(total_amount);

假设我们错误地在 total_amount 列上建立了索引，而不是在经常作为查询条件的 customer_id 列上建立索引。这可能导致以下问题：

  1. 查询性能下降： 当我们执行基于客户ID的查询时，由于没有索引支持，数据库可能需要进行全表扫描，导致查询性能下降。
sql 复制代码 
-- 查询某个客户的订单
SELECT * FROM orders WHERE customer_id = 123;
  1. 不利于频繁查询的列： 如果索引建立在不经常查询的列上，而不是在经常查询的列上，那么索引的效果将大打折扣。

合适的选择：

sql 复制代码 
CREATE INDEX idx_customer_id ON orders(customer_id);

在这个例子中，正确的选择是在经常用于查询的 customer_id 列上建立索引。这样，当执行基于客户ID的查询时，数据库可以快速定位到匹配的行，提高查询性能。

sql 复制代码 
-- 查询某个客户的订单
SELECT * FROM orders WHERE customer_id = 123;

结论：

选择合适的列建立索引是为了更好地支持经常使用的查询条件 ，从而提高查询性能。在设计索引时，需要考虑到应用的查询模式 、经常查询的列 、表的大小等因素，以制定合适的索引策略。不恰当的索引设计可能导致性能下降，增加查询时间。

2.唯一性原则

对于经常用于唯一性检查的列，例如主键，应该创建唯一索引。唯一索引可以防止重复数据的插入 ，并加速唯一性检查 。没有唯一索引时，插入新记录或者进行唯一性检查时可能会导致性能下降。

以下是一个示例说明：

假设有一个用户表 users，其中有一个名为 user_id 的列作为主键。我们想要确保 user_id 的唯一性。

创建没有唯一索引的情况：

sql 复制代码 
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100)
);

-- 尝试插入重复的 user_id
INSERT INTO users (user_id, username, email) VALUES (1, 'john_doe', 'john@example.com');
-- 这将导致主键冲突，并抛出错误

-- 尝试插入新的 user_id
INSERT INTO users (user_id, username, email) VALUES (2, 'jane_doe', 'jane@example.com');
-- 插入成功

在上述情况中，插入重复的 user_id 会导致主键冲突错误，这可能会在应用程序层面处理，但是在数据库内部，需要进行额外的检查，这可能影响性能。

创建唯一索引的情况：

sql 复制代码 
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100),
    UNIQUE KEY unique_user_id (user_id)
);

-- 尝试插入重复的 user_id
INSERT INTO users (user_id, username, email) VALUES (1, 'john_doe', 'john@example.com');
-- 这将导致唯一索引冲突，并抛出错误

-- 尝试插入新的 user_id
INSERT INTO users (user_id, username, email) VALUES (2, 'jane_doe', 'jane@example.com');
-- 插入成功

在这个例子中，通过在 user_id 列上创建唯一索引，数据库引擎可以更快速地进行唯一性检查。如果尝试插入已经存在的 user_id，将会触发唯一性索引冲突，从而防止重复数据的插入。这提高了数据库的数据完整性，同时也提高了查询的性能。

3.考虑多列索引

在某些情况下，创建多列索引（复合索引）可能比单列索引更有效。 复合索引（多列索引）可以提高多列查询的性能，特别是在涉及多个列的查询条件时。

以下是一个例子，说明在某些情况下创建复合索引可能比单列索引更有效：

假设有一个订单表 orders，包含以下列：order_id（主键），customer_id，order_date，product_id，quantity 等。

情景：

我们希望执行一个查询，找出某个客户在特定日期范围内购买的所有产品。

使用单列索引的情况：

sql 复制代码 
-- 创建单列索引
CREATE INDEX idx_customer_id ON orders (customer_id);

-- 查询特定客户在特定日期范围内的订单
SELECT * FROM orders
WHERE customer_id = 123 AND order_date BETWEEN '2022-01-01' AND '2022-01-31';

在这种情况下，单列索引 idx_customer_id 可以加速按客户ID过滤的查询，但对于包含 order_date 的范围条件，索引的效果可能相对较低。查询引擎可能需要更多的时间来过滤日期范围内的记录。

使用复合索引的情况：

sql 复制代码 
-- 创建复合索引
CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);

-- 查询特定客户在特定日期范围内的订单
SELECT * FROM orders
WHERE customer_id = 123 AND order_date BETWEEN '2022-01-01' AND '2022-01-31';

在这里，创建了一个复合索引 idx_customer_order_date，它同时包括 customer_id 和 order_date 列。这可以更好地支持上述查询，因为该索引涵盖了两个查询条件。查询引擎可以更有效地使用复合索引，以快速定位符合特定客户和日期范围的订单记录。

总体而言，使用复合索引的关键是理解查询中涉及的列，并创建一个涵盖这些列的索引 。这样可以减少查询时需要扫描的数据量，提高查询性能。然而，需要注意的是，过多的索引可能会影响写操作的性能，因此需要在创建索引时进行权衡。

4.避免在小表上建立索引

对于小型表，使用索引可能不会提高性能，反而增加了维护成本。在小表上建立索引可能不如在大表上建立索引更加划算。

以下是一个例子，说明在小表上建立索引可能不如在大表上建立索引更加划算的情况：

假设有一个小型表 products，包含以下列：product_id（主键），product_name，category_id，price等。

情景：

我们希望通过产品名称查询特定产品。

在小型表上建立索引的情况：

sql 复制代码 
-- 创建产品名称的索引
CREATE INDEX idx_product_name ON products (product_name);

-- 查询特定产品
SELECT * FROM products WHERE product_name = 'ExampleProduct';

在这里，我们为 product_name 列创建了一个索引。然而，由于表很小，对于查询来说，扫描整个表的成本可能相对较低。而且，在小型表上建立索引会增加存储和维护成本，因为索引本身也需要额外的存储空间，并且在插入、更新或删除记录时需要维护索引。

在大型表上建立索引的情况：

sql 复制代码 
-- 创建产品名称的索引
CREATE INDEX idx_product_name ON large_products_table (product_name);

-- 查询特定产品
SELECT * FROM large_products_table WHERE product_name = 'ExampleProduct';

在这里，我们考虑了一个更大的表 large_products_table。在这种情况下，通过为 product_name 列创建索引，查询引擎可以更快地定位和过滤数据，从而提高查询性能。在大型表上建立索引的开销相对较小，因为索引的维护成本可能在整个表中变得更加划算。

总体而言，对于小型表，除非查询中经常使用的列是非常关键的，否则创建索引可能不会带来明显的性能提升，而会增加额外的存储和维护成本。因此，在决定是否在小型表上创建索引时，需要进行权衡和评估。

5.使用前缀索引

对于长字符串列，可以考虑使用前缀索引，只对字符串的一部分进行索引。这有助于减小索引的大小，提高查询性能。

以下是一个例子，说明对于长字符串列，使用前缀索引的情况：

假设有一个包含长字符串列的表 text_data，其中的列为 long_text_column。

在整个字符串列上建立索引的情况：

sql 复制代码 
-- 创建整个字符串列的索引
CREATE INDEX idx_long_text_column ON text_data (long_text_column);

-- 查询以某个字符串开头的记录
SELECT * FROM text_data WHERE long_text_column LIKE 'prefix%';

在这里，我们在整个字符串列 long_text_column 上创建了一个索引。但如果该列包含非常长的文本数据，这个索引可能会变得很大，占用大量存储空间，并且在查询时可能不够高效。

使用前缀索引的情况：

sql 复制代码 
-- 创建字符串列的前缀索引
CREATE INDEX idx_prefix_long_text_column ON text_data (long_text_column(255));

-- 查询以某个字符串开头的记录
SELECT * FROM text_data WHERE long_text_column LIKE 'prefix%';

在这里，我们创建了一个前缀索引，只对字符串列的前 255 个字符进行索引。这样可以显著减小索引的大小，减少存储需求，并提高查询性能，因为查询引擎只需要处理较小的索引。

需要注意的是，在使用前缀索引时，我们需要根据实际数据情况选择合适的前缀长度。选择过小的前缀长度可能导致索引失效，而选择过大的前缀长度可能会降低性能提升效果。

总体而言，使用前缀索引是一种权衡存储和性能的有效策略，特别适用于长字符串列。

6.避免在频繁更新的列上建立索引

索引的维护会对表的更新操作产生影响。在频繁更新的列上建立索引可能导致性能下降，应该根据具体情况进行权衡。

以下是一个例子，说明索引对表更新操作的影响，并强调在频繁更新的列上建立索引时的权衡考虑：

假设有一个包含用户信息的表 users，其中包含一个经常更新的列 last_login_time。

在频繁更新的列上建立索引的情况：

sql 复制代码 
-- 创建 last_login_time 列的索引
CREATE INDEX idx_last_login_time ON users (last_login_time);

-- 更新用户的最后登录时间
UPDATE users SET last_login_time = NOW() WHERE user_id = 123;

在这里，我们在 last_login_time 列上创建了一个索引。当频繁地执行上述更新操作时，索引的维护会成为一个性能开销。每次更新 last_login_time 列时，不仅需要更新表中的数据行，还需要更新索引，这可能导致额外的I/O开销和锁定。

不在频繁更新的列上建立索引的情况：

sql 复制代码 
-- 不在 last_login_time 列上创建索引

-- 更新用户的最后登录时间
UPDATE users SET last_login_time = NOW() WHERE user_id = 123;

在这种情况下，如果 last_login_time 列没有索引，更新操作只需要修改表中的数据行，而不需要额外的索引维护操作。这可能导致更新操作更快，但同时也可能降低查询该列的性能，因为没有索引支持。

权衡考虑：

  • 读写比例： 如果表的更新操作远远多于查询操作，并且在频繁更新的列上建立了索引，可能会导致性能下降。在这种情况下，需要权衡索引的维护开销和查询性能。
  • 索引覆盖： 考虑查询中是否使用了频繁更新的列，以确定是否需要在该列上建立索引。索引的维护对于只涉及非索引列的更新操作影响较小。
  • 定期维护： 定期进行表和索引的维护，例如优化查询，重新组织索引等，以确保性能的最佳平衡。

总体而言，对于频繁更新的列，需要仔细考虑是否在该列上建立索引，并根据实际的读写操作比例和性能需求做出权衡决策。

7.分析查询语句和执行计划

在建立索引之前，通过分析查询语句和执行计划，了解查询的特点，选择合适的索引策略。

这有助于选择合适的索引策略以提高查询性能。以下是一个例子，演示如何通过分析查询语句和执行计划来选择合适的索引策略：

假设有一个包含订单信息的表 orders，其中包含列 order_id、customer_id、order_date、total_amount 等。

查询示例：

考虑一个查询，目标是找出特定客户在某个日期范围内的订单总金额：

sql 复制代码 
SELECT customer_id, SUM(total_amount)
FROM orders
WHERE customer_id = 123
  AND order_date BETWEEN '2022-01-01' AND '2022-01-31'
GROUP BY customer_id;

分析查询语句和执行计划：

  1. 查询条件： 查询条件涉及 customer_id 和 order_date 列。
  2. GROUP BY 子句： 使用了 GROUP BY customer_id，意味着查询要按客户进行分组。
  3. 聚合函数： 使用了 SUM(total_amount) 进行总金额的聚合计算。

可能的索引策略： 基于查询的特点，我们可以考虑以下索引策略：

  1. 复合索引：
    • 在 customer_id 和 order_date 列上创建复合索引，以支持查询条件。
    • 优点：可以快速定位特定客户和日期范围内的订单。
    • 缺点：对于 GROUP BY 子句，如果表中有大量不同的客户，可能需要额外的排序操作。
sql 复制代码 
CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);
  1. 覆盖索引：
    • 在 customer_id、order_date 和 total_amount 列上创建复合索引，以覆盖查询和聚合的所有列。
    • 优点：避免了对表的额外访问，性能更高。
    • 缺点：索引的维护成本可能较高，特别是在频繁更新的情况下。
sql 复制代码 
CREATE INDEX idx_covering ON orders (customer_id, order_date, total_amount);

选择合适的索引策略： 在实际应用中，我们需要权衡不同策略的优缺点。可能需要考虑的因素包括：

  • 表的大小和数据分布。
  • 查询的频率和性质。
  • 对于写入操作的敏感性。
  • 系统的整体性能要求。

通过分析查询语句、执行计划以及实际场景的特点，可以更好地选择适合应用需求的索引策略，以提高查询性能。在实施索引之前，可以使用 EXPLAIN 或其他数据库性能分析工具来评估执行计划，以确保所选策略的有效性。

8.定期维护索引

随着表的数据不断变化，索引的效果也会发生变化。定期对索引进行优化和维护，有助于保持查询性能。

以下是一个例子，说明随着数据变化，为什么索引优化是必要的：

假设有一个订单表 orders，包含列 order_id（主键）、customer_id、order_date、total_amount 等。

情景：

初始时，订单表中的数据量相对较小，可以在 customer_id 列上创建一个单列索引来提高查询性能：

sql 复制代码 
-- 创建初始的单列索引
CREATE INDEX idx_customer_id ON orders (customer_id);

随着数据变化的情况： 随着时间推移，订单数据不断增加，表的大小变大。原先的单列索引可能不再足够有效，因为表中数据的分布和查询模式可能发生了变化。

可能的问题：

  1. 数据分布变化： 随着数据的不断插入和删除，原先的索引可能变得不再均匀，导致某些值的频繁查询效果变差。
  2. 查询模式变化： 随着业务的变化，可能会引入新的查询模式，需要更适合的索引结构。

定期索引优化和维护： 定期对索引进行优化和维护是保持查询性能的关键。以下是可能的维护步骤：

  1. 重新组织索引： 使用数据库管理工具或命令，对表的索引进行重新组织。这有助于提高索引的性能，特别是在数据分布不均匀的情况下。
sql 复制代码 
-- 重新组织索引
OPTIMIZE TABLE orders;
  1. 重新评估索引策略： 随着数据变化，重新评估原有的索引策略是否仍然适用。可能需要添加、删除或修改索引，以满足新的查询模式和数据分布。
sql 复制代码 
-- 示例：删除旧索引，创建新索引
DROP INDEX idx_customer_id ON orders;
CREATE INDEX idx_new_index ON orders (customer_id, order_date);
  1. 统计信息更新： 更新表的统计信息，帮助查询优化器生成更准确的执行计划。
sql 复制代码 
-- 更新统计信息
ANALYZE TABLE orders;
  1. 监控查询性能： 定期监控数据库的性能，并根据性能指标调整索引策略。

注意： 索引维护的频率取决于数据变化的速度和查询需求的变化。在高度动态的系统中，可能需要更频繁地进行索引维护。

通过定期的索引优化和维护，可以确保索引仍然对查询有效，提高数据库性能，并适应数据变化和业务需求的变化。

9.监控数据库性能

建立索引后，需要监控数据库的性能，特别是在实际生产环境中。根据监控结果，可以调整索引的设计和使用。

以下是一个例子，说明如何通过监控数据库性能来调整索引的设计和使用：

场景：

假设有一个包含订单信息的表 orders，其中包含列 order_id（主键）、customer_id、order_date、total_amount 等。为了优化查询性能，我们在 customer_id 列上创建了一个单列索引。

监控数据库性能的步骤：

  1. 使用性能监控工具： 使用数据库管理工具、性能监控软件或命令行工具来监控数据库性能。一些常见的性能监控工具包括 MySQL 的 Performance Schema、Percona Toolkit 等。

  2. 查看查询执行计划： 定期查看数据库中运行的查询的执行计划。执行计划提供了关于查询如何被执行的详细信息，包括使用的索引和执行的步骤。

sql 复制代码 
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;

  1. 分析查询性能指标： 关注一些关键的性能指标，如查询响应时间、查询吞吐量、查询执行计划的扫描次数等。这些指标可以帮助确定哪些查询可能受到性能问题的影响。

  2. 监测索引利用率： 查看索引的利用率，即索引被查询的频率。如果一个索引很少被使用，可能需要重新评估它的设计和是否需要删除。

sql 复制代码 
SHOW INDEX FROM orders;

调整索引的设计和使用：

  1. 添加新索引： 根据查询需求和性能监控结果，考虑添加新的索引来支持更频繁的查询。例如，如果某个查询中使用了多个列，可以考虑创建复合索引。
sql 复制代码 
CREATE INDEX idx_new_index ON orders (customer_id, order_date);
  1. 删除不必要的索引： 如果某个索引很少被使用，或者不再满足查询需求，考虑删除该索引以减少维护开销。
sql 复制代码 
DROP INDEX idx_old_index ON orders;
  1. 重新组织索引： 定期对索引进行重新组织，以优化其性能。这对于频繁更新的表尤为重要。
sql 复制代码 
OPTIMIZE TABLE orders;
  1. 调整查询： 如果性能监控结果显示某些查询的性能问题，可能需要调整查询语句或者重写查询以优化性能。

注意： 在进行索引调整时，需要谨慎操作，避免引起不必要的影响。最好在非生产环境中测试任何索引变更，并在变更后重新进行性能监控以确保性能改善。

通过定期的性能监控和调整索引的设计和使用，可以保持数据库的高性能，并适应不断变化的查询需求和数据分布。

10.使用适当的存储引擎

不同的存储引擎对索引的支持和实现方式确实有所不同，每个存储引擎都有其独特的特性和适用场景。 以下是一些常见的 MySQL 存储引擎，以及它们在索引方面的一些不同之处：

  1. InnoDB 存储引擎：

    • 支持的索引类型： InnoDB 支持主键索引、唯一索引、全文索引、空间索引等多种类型。
    • 聚簇索引： InnoDB 的主键索引是聚簇索引，数据行的存储顺序与主键的顺序一致。非主键索引实际上包含了对应数据行的主键值，因此查询非主键索引时需要两次查找。

  2. MyISAM 存储引擎：

    • 支持的索引类型： MyISAM 支持主键索引、唯一索引、全文索引等。
    • 非聚簇索引： MyISAM 的索引是非聚簇索引，数据行和索引分开存储。非主键索引直接包含了指向数据行的指针，因此查询效率较高。

  3. MEMORY 存储引擎：

    • 支持的索引类型： MEMORY 存储引擎支持主键索引、唯一索引，但不支持全文索引等其他类型。
    • 基于哈希的索引： MEMORY 存储引擎的索引是基于哈希的，适用于等值查询。但它不适用于范围查询和排序操作。

  4. NDB 存储引擎（NDB Cluster）：

    • 支持的索引类型： NDB 存储引擎支持哈希索引和 B 树索引。
    • 分布式存储： NDB 存储引擎是一个分布式存储引擎，适用于大规模的集群环境。索引的实现考虑了分布式环境的特点。

  5. TokuDB 存储引擎：

    • 支持的索引类型： TokuDB 支持 B 树索引，但其主要特点是支持 Fractal Tree 索引结构，这种结构对于范围查询和插入操作具有优势。

根据需求选择适当的存储引擎：

  • 如果需要事务支持 、行级锁 、外键约束 等特性，可以选择 InnoDB。
  • 如果对查询进行频繁优化 ，而且对于事务完整性的要求不那么高 ，可以选择 MyISAM。
  • 如果需要将整个表存储在内存中 以提高读取速度，并且可以接受数据在服务重启时丢失，可以选择 MEMORY 存储引擎。
  • 如果需要分布式存储和处理大规模数据集 ，可以选择 NDB 存储引擎。
  • 如果需要在大量写入和查询的场景 中具有优异性能，可以考虑 TokuDB 存储引擎。

总体而言，根据具体的应用需求和性能特点选择适当的存储引擎，以确保系统在不同方面都能取得最佳性能。
总的来说，建立索引需要综合考虑数据库表的结构、查询模式、数据量等因素，根据具体情况制定索引策略。不是越多越好，而是要根据实际需求选择合适的列和类型建立索引。

相关推荐
喵手10 分钟前
如何利用Java的Stream API提高代码的简洁度和效率？
java·后端·java ee
掘金码甲哥16 分钟前
全网最全的跨域资源共享CORS方案分析
后端
m0_4805026423 分钟前
Rust 入门 生命周期-next2 (十九)
开发语言·后端·rust
张醒言30 分钟前
Protocol Buffers 中 optional 关键字的发展史
后端·rpc·protobuf
鹿鹿的布丁1 小时前
通过Lua脚本多个网关循环外呼
后端
墨子白1 小时前
application.yml 文件必须配置哇
后端
xcya1 小时前
Java ReentrantLock 核心用法
后端
用户466537015051 小时前
如何在 IntelliJ IDEA 中可视化压缩提交到生产分支
后端·github
小楓12011 小时前
MySQL數據庫開發教學(一) 基本架構
数据库·后端·mysql
天天摸鱼的java工程师1 小时前
Java 解析 JSON 文件：八年老开发的实战总结（从业务到代码）
java·后端·面试
热门推荐
01UV安装并设置国内源02DeepSeek更新！速览DeepSeek V3.1新特性03Qwen3-Coder 快速上手教程 | Qwen Code + Claude Code04KGG转MP3工具|非KGM文件|解密音频05【2025.08.06最新版】Android Studio下载、安装及配置记录（自动下载sdk）06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接072025最新国内服务器可用docker源仓库地址大全（2025年8月更新）08阿里开源首个图像生成基础模型——Qwen-Image本地部署教程，超强中文渲染能力刷新SOTA！09NVIDIA显卡驱动、CUDA、cuDNN 和 TensorRT 版本匹配指南10TRAE 规则（Rules）配置指南：个人习惯、团队规范与最佳实践