mysql 数据库中索引原理分析说明

索引就像一本书的目录，MySQL 使用它来快速查找数据。
聚集索引就像您可以直接找到的文本。
非聚集索引，比如目录，先查找目录，再查找目录。
您想选择聚集索引吗？数据很小并且经常排序。
你愿意选择不聚集吗？大量的价值和频繁的更新。
不要使用主键进行聚合，不要盲目建立索引。
优化的索引，快速的查询，卓越的性能。

sql 中 index 用法_sql 中 index 创建索引教程

联合索引最左匹配原则

说实话，联合索引使用起来很有趣，但也有很多风险。
当我们接管旧系统时，我们在索引方面遇到了麻烦。
严格来说，最左匹配原则是MySQL使用连接索引时的原则。
就像排队买票一样。
您必须先转到最左边的窗口。

以我们公司的订购系统为例。
该表有关联索引（用户ID、订单时间、产品类型）。
假设我们检查“用户 ID 为 1 2 3 、订单时间为 2 02 3 年的订单”。
这时，由于MySQL是从左到右顺序匹配的，所以可以使用索引。
但是，如果我们直接检查“产品类型是服装”，则标签不起作用 - 它会跳过最左边的列。

最左边的约束尤其严格。
例如，如果使用范围查询（>、<、BETWEEN），则以下列完全无用。
记得有一次查看“用户ID为1 2 3 ，订单数量超过1 000”。
尽管用户 ID 部分已标记。
查询数量段直接使索引无效。
当时我不明白为什么要这样设计，后来再详细了解我认为范围查询会破坏所有后续列上索引的使用。

但是，最左边的匹配一点也不严格。
如果您选中“用户 ID 为 1 2 3 ，产品类型为服装”，则它并不完全匹配所有列。
只要存在从左到右的序列匹配，MySQL 将继续使用索引的用户 ID 部分。
这称为部分匹配，使用起来相当灵活。

依赖于最左边的匹配掩码标签。
例如，我们有一个只需要用户 ID 和命令时间的查询。
如果联合索引（用户ID、下单时间、商品类型）包含这两列；可以直接从索引检索数据，而无需返回图表。
但如果查询条件通过了用户ID。
被覆盖的索引不再起作用。

设计索引时要特别注意列顺序。
我们在系统中学到的一个教训是将最常见的查询列放在最左侧。
例如，“按用户ID搜索”比“按产品类别搜索”出现频率高得多，因此将用户ID放在左侧。
另外，范围查询列一定不能放在左边，否则后面的一切都会杂乱。
例如，（用户 ID、订单时间）比（订单时间，用户 ID）好得多。

还必须避免重复标签。
例如，创建了（用户ID，订单时间），再次创建（用户ID）将是一种浪费 - 前者可能会隐藏后者。
我们在系统初期就遇到了这个问题，最终清理了不必要的索引，性能立即得到改善。

我不亲自处理分布式交易细节；但最左匹配原则对于单表索引设计来说绝对是基础。
想一想；数据库是否正确使用索引。
由于每天要处理数亿个查询，几秒钟的性能差异可能会带来巨大的损失。
因此，必须仔细注意列顺序和范围查询约束。