因此，仅针对最常查询和最常见的数据列进行索引。

MySQL中同一数据表中的索引总数限制为16。

索引存储类型

B-Tree索引

Innodb使用B+树。 B+树：每个叶子节点都包含一个指向下一个叶子节点的指针，该指针促进了叶子节点的范围遍历。

B树通常意味着所有值都存储在顺序中，并且每个叶页到根到根的距离都是相同的，这非常适合查找范围数据。

b-tree可以使用索引，=，=，=，=，在in和in之间以及不从通配符开始的喜欢。

索引查询

您可以使用B-Tree索引查询完整的关键字，关键字范围和关键字前缀，但是必须确保查询基于索引的最左侧前缀。

假设有下表：

创建表people（last_name varchar（50）不是null，first_name varchar（50）不是null，dob date not null，性别枚举（\’m\’，\’f\’）而不是null，key（last_name，first_name，dob））;其组合索引包含表中每一行的last_name，first_name和Dob列。结构大致如下：

查询索引的最左前缀：

查询必须从索引的最左列开始，否则不能使用索引。例如，您无法直接使用该索引来找到某天出生的人。不能跳过某个索引列。例如，您无法使用索引找到一个姓氏史密斯且在某一天出生的人。存储引擎无法在索引中使用范围条件右侧的列。例如，如果您的查询语句是last_name=\’smith\’和first_name，例如\’j\’和dob=\’1976-12-23\’，则查询只会使用索引中的前两个列，因为就像范围查询一样。

匹配完整值：指定索引中所有列的特定值。例如，上图中的索引可以帮助您找到1960-01-01出生的古巴·艾伦。匹配最左边的前缀：您可以使用索引找到一个姓氏是艾伦的人，只需使用索引中的第一列即可。匹配一个列前缀：例如，您可以使用索引找到一个姓氏以J开头的人，该名称仅在索引中使用1列。匹配一系列值：您可以使用索引来查找艾伦和巴里摩尔之间的姓氏，只需使用索引中的第一列即可。匹配一个部分并匹配另一部分的范围：您可以使用索引找到一个姓氏是艾伦（Allen）且名字以字母K开头的人。仅索引的查询：如果列查询全部在索引中，则无需再次读回元组I/O。 （概述索引：该索引的叶节点已经包含要查询的数据，因此无需返回表格查询。如果该索引包含所有符合查询的数据，则称为概述索引。）:01

索引排序

，您还可以使用B-Tree Index for Index cortex（订单）（订单）。有必要确保按索引的最左前缀执行顺序。

在MySQL中，有两种方法可以生成有序的结果集：

使用filesort按索引顺序扫描。如果所解释的类型列的值为“索引”，则表示MySQL使用索引扫描进行排序。

按索引顺序进行扫描：

您可以使用相同的索引同时搜索和排序操作：

当索引顺序与按顺序排列的列顺序相同，并且所有列都朝着相同的方向（全部上升或全部下降）时，您可以使用索引进行排序。按子句和查询子句的订单限制是相同的：需要满足索引的最左前缀的要求。在一个情况下，按子句的顺序无法满足索引的最左前缀的要求，也就是说，当领先列是常数时：为where子句或加入子句指定的前导列指定常数。

如果查询正在连接多个表，则仅在所有列按第一个表的列时使用索引。在其他情况下，FileSort文件将进行排序。使用FileSort：

当MySQL无法与索引进行排序时，它将使用自己的排序算法（快速排序算法）在内存中对数据进行排序（sort buffer）;

如果无法加载内存，它将将数据块上的数据块，对数据块进行排序，然后将块合并为有序结果集（实际上，使用临时表，是外部排序）。对于FileSort，MySQL具有两个排序算法：

两条通信算法首先提取需要排序的字段，以及可以直接位于相关行数据的指针信息，然后将它们分组在设置内存中（通过参数sort_buffer_size设置）。完成排序后，再次通过行指针信息再次检索所需的列。

该算法是在MySQL 4.1之前采用的算法，它需要对数据进行两次访问，尤其是第二个读取操作将导致大量随机I/O操作。另一方面，内存开销很小。

单个通过此算法一次将所有必需的列取出所有必需的列，并在对内存中排序后直接输出结果。

自MySQL 4.1版本以来，请使用此算法。它减少了I/O时间的数量，更有效，但内存较高。如果我们取出不需要的列，它将大大浪费分类过程所需的内存。

In versions after MySQL 4.1, you can control whether MySQL chooses the first sorting algorithm or the second type by setting the max_length_for_sort_data parameter: When the total size of all large fields taken out is greater than the setting of max_length_for_sort_data, MySQL will choose to use the first sorting algorithm, otherwise, the second type will be selected.

对加入操作进行排序时，如果仅订单仅涉及第一表的列，则MySQL在表上执行Filesort操作，然后执行连接处理。此时，请解释输出“使用filesort”；否则，MySQL必须为查询结果集生成临时表，并在连接完成后执行Filesort操作。目前，请解释输出“使用临时；使用filesort”。

为了尽可能提高排序性能，我们自然更喜欢使用第二种分类算法，因此非常有必要在查询中删除所需的列。

聚簇索引(cluster index)

表只能有一个群集索引。

当前，只有SolidDB和InnoDB支持群集索引，而Myisam不支持聚类索引。一些DBMS允许用户指定群集索引，但是MySQL的存储引擎尚未支持。

InnoDB的聚簇索引：

InnoDB建立了主要键的聚类索引。如果您没有指定主键，InnoDB将用唯一且非零值的索引替换它。如果不存在这样的索引，InnoDB将定义一个隐藏的主键，然后创建群集索引。 InnoDB默认使用聚类索引来组织数据。如果您使用InnoDB，并且不需要特殊的聚类索引，那么一个好的做法是使用代理主键（替代键）——与应用程序中的数据无关。最简单的方法是使用Auto_Increment列，该列确保按顺序插入记录，并可以提高使用主要键进行连接的查询性能。应尽可能避免随机聚类的主键。例如，字符串主键是一个不好的选择，它使插入操作随机。

一般而言，DBMS将以群集索引的形式存储实际数据，这是其他次要索引的基础：

聚类索引（主要索引）：主键索引非簇索引（第二个索引）：次级索引

聚簇索引结构：

群集索引的结构大致如下：

聚类索引：节点页面仅包含索引列，而LEAF页面包含行的所有数据。聚类索引是“表”，因此不需要独立的行存储。聚类索引可确保具有相似关键字值的元素的物理位置也相似（因此不应构建字符串类型，尤其是随机字符串，这将导致系统执行大量的运动操作）。

次级索引：叶节点保存了一个指指指的是，该指针指的是行的物理位置，但行的主要键值。这意味着，通过搜索二级索引行，存储引擎需要：1。找到辅助索引的叶节点以获得相应的主要键值，2。基于此主要键值在群集索引中找到相应的行。有两个B-Tree查找，而不是一个。

覆盖索引对于InnoDB表特别有用，因为InnoDB使用群集索引来组织数据，并且如果辅助索引包含查询所需的数据，则不再需要在群集索引中查找。

聚簇索引（InnoDB）和二级索引（MyISAM）数据布局比较：

创建表Layout_test（col1 int not null，col2 int not null，primary键（col1），key（col2））； yisammyisam在插入顺序上存储磁盘上的数据：

左开始是行号（行号），从0开始。由于元组的大小是固定的，因此Myisam可以从表的开始位置轻松找到某个字节的位置。

Myisam创建的索引结构大致如下：

COL1主钥匙指数：

Myisam不支持聚类索引。索引中的每个叶节点仅包含一个行号，并且叶节点以Col1的顺序存储。

COL2非主要密钥指数：

在Myisam中，主键与其他索引没有什么不同。主键只是一个称为primary的独特的，非空的索引，叶子节点以col2为单位。

InnodBCol1主键索引，即聚类索引：

聚类索引中的每个叶节点都包含主键的值，事务ID，交易和MVCC的回滚指针以及其余列（例如COL2）。

COL2非主要密钥指数，即次要指数：

InnoDB的次要索引的叶子包含主键的值，而不是行点。此策略减少了移动数据或数据页面分割时维护次级索引的开销，因为InnoDB不需要更新索引的行指针。

聚类索引+辅助索引表和非簇索引表之间的比较

Hash索引

哈希索引是基于哈希表实现的，只有准确索引所有列的查询都是有效的。

对于每行数据，存储引擎为所有索引列计算哈希代码。哈希索引将所有哈希代码存储在索引中，并在哈希表中保存一个指向每个数据的指针。

在MySQL中，只有内存存储引擎显示支持哈希索引，这是内存表的默认索引类型，尽管内存表也可以使用B树索引。

内存存储引擎支持非唯一哈希索引，在数据库字段中很少见：如果多个值具有相同的哈希代码，则该索引将其行指针保存到与链接列表相同的哈希条目中。

假设您创建下表：

创建表Testhash（fname varchar（50）非null，lname varchar（50）非null，使用哈希（fname））发动机=内存；包含的数据如下：

假设该索引使用Hash函数f（），如下：

f（\’arjen\’）=2323f（\’baron\’）=7437f（\’peter\’）=8784f（\’vadim\’）=2458目前，索引的结构大致如下：

哈希索引存储：哈希值+数据线指针

当您从testhash中执行选择lname时，其中fname=\’peter\’; MySQL将计算“彼得”的哈希值，然后查询索引的行指针。因为F（\’Peter\’）=8784，MySQL将在索引中寻找8784，并获得记录3的指针。

哈希指数有一些局限性：

由于该索引仅包含哈希代码和记录指针，因此MySQL无法避免使用索引读取记录，也就是说，每当使用Hash索引查询记录指针时，都会读取原始主体以检索数据。不能使用哈希索引排序。哈希索引不支持键的部分匹配，因为哈希值是通过整个索引值计算得出的。哈希索引仅支持相等的值比较，例如lusther=，in（）和=。对于价格100的地方，无法加速查询。除非有许多哈希冲突（不同的索引列值具有相同的哈希值），否则访问哈希索引非常快。当发生哈希冲突时，存储引擎必须在链接列表中遍历所有行指针，并逐行比较直到找到符合条件的所有行。如果存在许多哈希冲突，那么一些索引维护操作也将非常昂贵。从表中删除行时，存储引擎将带有相应的哈希值的链接列表中的每一行，并查找并删除对相应行的引用。冲突越多，成本就越大。 InnoDB引擎具有称为“自适应哈希指数”的特殊功能，该功能由MySQL自动管理，不需要DBA的人类干预。默认情况下，我们可以通过参数Innodb_adaptive_hash_index禁用此功能。

当InnoDB注意到某些索引值经常使用时，它会根据缓冲池中的B+树索引在内存中创建另一个哈希索引，因此BTree索引还具有哈希索引的一些优势，例如快速哈希查找。

仅用于等值比较，例如=，=，in;不能用来对InnoDB的官方文档进行排序，表明在启用自适应哈希索引后，读取性能可以提高2次，并且对于辅助索引的连接操作，可以将性能提高5次。

空间(R-Tree)索引

Myisam支持空间索引，主要用于地理空间数据类型，例如几何形状。

全文(Full-text)索引

全文索引是Myisam的特殊索引类型。它在文本中搜索关键字，主要用于全文检索。

MySQL InnoDB自5.6起就支持了全文索引，但是InnoDB不支持中文，日语等。因为这些语言没有分离器。您可以使用插件来帮助实现中文，日语等的全文索引。请参阅：12.9.5全文限制

索引使用

MySQL建立索引类型

单列索引，即索引仅包含一个列，并且表可以具有多个单列索引，但这不是组合索引。组合索引，即搜索包含多个列。索引是在存储引擎而不是在服务器层中实现的。因此，每个存储引擎的索引不一定是相同的，并且并非所有存储引擎都支持所有索引类型。

普通索引

这是最基本的指数，没有限制。普通索引的唯一任务（由关键字键或索引定义的索引）是加快访问数据的访问。因此，仅适用于最经常出现在查询条件（列=…）或排序条件（按列的顺序）的数据列创建索引。

它具有以下方法来创建：

创建索引在mytable（用户名（长度））上创建索引索引名；

如果是char，则长度可能小于场的实际长度。如果是斑点和文本类型，则必须指定长度，以下相同。

修改表结构更改mytable添加索引[indexName]（用户名（length））

创建表时，直接指定创建表mytable（id int not null，用户名varchar（16）而不是null，index [indexName]（用户名（length）））;

用于删除索引的语法：mytable上的drop index [indexName]；

唯一索引

与先前的正常索引相似，其区别在于，正常索引允许索引数据列包含重复值。唯一索引列的值必须是唯一的，但是允许有空值。如果是组合索引，则列值的组合必须是唯一的。

它具有以下方法来创建：

创建索引在mytable（用户名（长度））上创建唯一索引索引名

修改表结构更改mytable on（用户名（长度））上添加唯一[indexname]

创建表时，直接指定创建表mytable（id int而非null，用户名varchar（16）而不是null，unique [indexName]（username（length）））;

主键索引

它是一个特殊的唯一索引，不允许零值。表只能有一个主键。

通常，创建表格时同时创建主键索引：

创建表mytable（id int而非null，用户名varchar（16）而不是null，主键（id））;当然，也可以使用Alter命令。

同样，外键指数

如果为外键字段定义了外键约束，MySQL将定义一个内部索引，以最有效地管理和使用外键约束。

组合索引

要生动地比较单列索引和组合索引，请在表中添加多个字段：

创建表mytable（id int not null，用户名Varchar（16）不是null，City Varchar（50）而不是null，age int int int int int not null）;

为了进一步提取MySQL的效率，我们必须考虑建立复合指数。它是将姓名，城市和年龄创建为索引：

Alter表Mytable添加索引name_city_age（名称（10），城市，年龄）;

创建表格时，用户名长度为16，这里使用10。这是因为通常，名称的长度将不超过10，这将加快索引查询速度，降低索引文件的大小，并提高插入的更新速度。

建立这样的组合指数实际上等同于建立以下三组组合索引：

用户名，城市，年龄

用户名，城市

用户名

为什么没有像城市和年龄这样的组合索引？这是由于MySQL组合索引“最左前缀”的结果。一个简单的理解是从最左边的组合开始。并非所有包含这三列的查询都会使用此组合索引。以下SQL将使用此组合索引：

从mytable whrey用户名=\’admin\’和city=\’zhengzhou\’选择*

从mytable whrey用户名=\’admin\’中选择*

以下将不会使用：

从Mytable Whree Age=20和City=\’Zhengzhou\’中选择*

从Mytable Whree City=\’Zhengzhou\’选择*

如果在用户名，城市和年龄上建立了单列索引，并且该表具有3个单列索引，则查询期间合并索引的效率将非常不同，这远低于我们的合并索引。因为尽管目前有三个索引，但MySQL只能使用它认为似乎是最有效的单列索引的索引。

建立索引的时机

一般来说，出现在地点和加入中的列需要索引，但事实并非如此，因为MySQL的B树仅使用索引，=，=，=，=，=，在IN和类似之间并不是从通配符开始。

例如：

从mytable t左加入mytable m上的t.name=m.username中的t.name=20 and m.city=\’zhengzhou\’\’

目前，有必要索引城市和年龄。由于Mytable表的用户名也出现在JOIN子句中，因此也有必要进行索引。

正确使用索引

使用（B-Tree）索引时，有一些技巧和预防措施：

索引设计：

尝试使用数字类型（简单数据类型）。如果仅包含数值信息的字段不应被设计为字符类型，则将降低查询和连接的性能并增加存储开销。这是因为在处理查询和连接时，引擎将字符串中的每个字符比较，而对于数字类型，则只需进行一个比较即可。

尽量不要使MySQL中字段null的默认值。无效值的列难以查询和优化，因为它们使索引，索引统计和比较操作更加复杂。

该索引将不包含具有空值的列。只要列包含零值，它就不会包含在索引中。只要复合索引中的一列包含零值，对于此复合索引，此列是无效的。

因此，在设计数据库时，我们尽量不要使字段null的默认值。除非您要存储null，否则我们应该将列指定为非null。您应该使用0，特殊值或一个空字符串而不是空字符串。

前缀索引和索引有选择地索引字符串，如果可能的话，应指定前缀长度。

对于Blob，文本或非常长的VARCHAR类型的列，必须使用前缀索引，因为MySQL不允许索引这些列的全长。

前缀索引是使索引较小，更快的有效方法，但另一方面，它也具有缺点：MySQL不能使用前缀索引订购和组，也无法使用前缀索引来覆盖扫描。

一般而言，特定前缀的选择性也足够高以达到查询性能。

例如，如果有一个带有char（255）的列，并且大多数值在前10或20个字符中是唯一的，则不要索引整列。

简短的索引不仅可以提高查询速度，还可以节省磁盘空间和I/O操作。在大多数应用程序中，数据库中的字符串数据主要基于各种名称。将索引长度设置为10到15个字符足以将搜索范围缩小到一些数据记录。

通常，索引索引的某些字符可以大大节省索引空间并提高索引效率。但这也将降低索引的选择性。

索引的选择性是指未重复与数据表中记录总数的索引值（基数）的比率。索引的选择性越高，查询效率越高，因为高选择性索引允许MySQL在搜索时过滤更多行。唯一的索引选择性是1，这是最佳索引选择性和最佳性能。

诀窍是选择足够长的前缀以确保高选择性，而不会太长（节省空间）。前缀应足够长，以使前缀索引的选择性接近整列的索引。换句话说，前缀的“基数”应接近完整列的“基数”。

要确定前缀的适当长度，您需要找到最常见值的列表，然后将其与最常见的前缀列表进行比较。例如，以下查询：

选择计数（*）为CNT，来自Sakila的City.city_demo组，按CNT DESC限制10；

选择（*）作为cnt，左（城市，7）作为sakila的perf。city_demo组按CNT desc desc limit 10；

直到此前缀的选择性接近完整列的选择性。

计算适当前缀长度的另一种方法是计算完整列的选择性，并使前缀接近完整列的选择性的选择性，如下：

从sakila.city_demo中选择计数（不同的城市）/count（*）；

从sakila.city_demo中选择计数（左（城市，7））/count（*）；

使用唯一的索引来考虑列中值的分布。索引列的基数越大，索引效应越好。

例如，存储出生日期的列具有不同的值，因此很容易区分行。用于记录性别的列仅包含“ M”和“ F”，因此索引此列不是很有用，因为无论搜索哪个值，将获得大约一半的行。

使用复合索引而不是多列索引来索引多列索引

（组合索引）与多个列索引MySQL在解析执行上是不一样的，如果在explain中看到有索引合并（即MySQL为多个列索引合并优化），应该好好检查一下查询的表和结构是不是已经最优。

注意重复/冗余的索引、不使用的索引MySQL允许在相同的列上创建多个索引，无论是有意还是无意的。大多数情况下不需要使用冗余索引。

对于重复/冗余、不使用的索引：可以直接删除这些索引。因为这些索引需要占用物理空间，并且也会影响更新表的性能。

索引使用：

如果对大的文本进行搜索，使用全文索引而不要用使用 like ‘%…%’like语句不要以通配符开头对于LIKE：在以通配符%和_开头作查询时，MySQL不会使用索引。like操作一般在全文索引中会用到（InnoDB数据表不支持全文索引）。

例如下句会使用索引：

SELECT * FROM mytable WHERE username like\’admin%\’

而下句就不会使用：

SELECT * FROM mytable WHEREt Name like\’%admin\’

不要在列上进行运算索引列不能是表达式的一部分，也不是是函数的参数。

例如以下两个查询无法使用索引：

1）表达式： select actor_id from sakila.actor where actor_id+1=5;

2）函数参数：select … where TO_DAYS(CURRENT_DATE) – TO_DAYS(date_col)<=10;

尽量不要使用NOT IN、<>、!= 操作应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

对于not in，可以用not exists或者（外联结+判断为空）来代替；很多时候用 exists 代替 in 是一个好的选择： select num from a where num in(select num from b) 用下面的语句替换： select num from a where exists(select 1 from b where num=a.num)

对于<>，用其它相同功能的操作运算代替，如a<>0 改为 a>0 or a<0

or条件用 or 分割开的条件， 如果 or 前的条件中的列有索引， 而后面的列中没有索引， 那么涉及到的索引都不会被用到。

应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： 假设num1有索引，num2没有索引，查询语句select id from t where num1=10 or num2=20会放弃使用索引，可以改为这样查询： select id from t where num1=10 union all select id from t where num2=20，这样虽然num2没有使用索引，但至少num1会使用索引，提高效率。

组合索引的使用要遵守“最左前缀”原则\’组合索引：当不需要考虑排序和分组时，将选择性最高的列放在前面通常是最好的。

例子：

CREATE TABLE People ( last_name varchar(50) not null, first_name varchar(50) not null, birthday date not null, gender enum(\’m\’, \’f\’) not null, key(last_name, first_name, birthday));查询必须从索引的最左边的列开始，否则无法使用索引。例如，你不能直接利用索引查找在某一天出生的人。不能跳过某一索引列。例如，你不能利用索引查找last name为Smith且出生于某一天的人。存储引擎不能使用索引中范围条件右边的列。例如，如果你的查询语句为WHERE last_name=\”Smith\” AND first_name LIKE \’J%\’ AND dob=\’1976-12-23\’，则该查询只会使用索引中的前两列，因为LIKE是范围查询。使用索引排序时，ORDER BY也要遵守“最左前缀”原则当索引的顺序与ORDER BY中的列顺序相同，且所有的列是同一方向（全部升序或者全部降序）时，可以使用索引来排序。ORDER BY子句和查询型子句的限制是一样的：需要满足索引的最左前缀的要求，有一种情况下ORDER BY子句可以不满足索引的最左前缀要求，那就是前导列为常量时：WHERE子句或者JOIN子句中对前导列指定了常量。如果查询是连接多个表，仅当ORDER BY中的所有列都是第一个表的列时才会使用索引。其它情况都会使用filesort文件排序。

如果列类型是字符串，那么一定记得在 where 条件中把字符常量值用引号引起来，否则的话即便这个列上有索引，MySQL 也不会用到的，因为MySQL 默认把输入的常量值进行转换以后才进行检索。 例如：

任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段如果 MySQL 估计使用索引比全表扫描更慢，则不使用索引。当索引列有大量数据重复时,查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

索引性能测试与索引优化

只有当数据库里已经有了足够多的测试数据时，它的性能测试结果才有实际参考价值。如果在测试数据库里只有几百条数据记录，它们往往在执行完第一条查询命令之后就被全部加载到内存里，这将使后续的查询命令都执行得非常快——不管有没有使用索引。只有当数据库里的记录超过了1000条、数据总量也超过了 MySQL服务器上的内存总量时，数据库的性能测试结果才有意义。

在不确定应该在哪些数据列上创建索引的时候，人们从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出来。

查看索引使用情况：

如果索引正在工作，Handler_read_key 的值将很高，这个值代表了一个行被索引值读的次数，很低的值表明增加索引得到的性能改善不高，因为索引并不经常使用。Handler_read_rnd_next 的值高则意味着查询运行低效，并且应该建立索引补救。这个值的含义是在数据文件中读下一行的请求数。如果正进行大量的表扫描， Handler_read_rnd_next 的值较高，则通常说明表索引不正确或写入的查询没有利用索引。具体如下：

从上面的例子中可以看出，目前使用的 MySQL 数据库的索引情况并不理想。

参考资源：

《深入浅出MySQL》

用户评论

早不爱了

真的对数据库知识不太懂，看了这篇文章感觉终于有点明白了！比如索引的作用和类型的讲解都说得非常清楚，很实用～

    有16位网友表示赞同！

服从

我之前一直觉得mysql速度慢，看了文章才知道原来是索引没用好呀！现在赶紧去研究下优化一下数据库吧！

    有8位网友表示赞同！

念旧是个瘾。

MySQL 索引确实是一个重要的概念，这篇文章总结得真是不错！特别是多种索引类型的对比分析，很有帮助。

    有18位网友表示赞同！

軨倾词

我觉得这篇文章缺点是讲解太简略了，对于一些比较高级的索引类型，比如全文检索索引，写的不够深入。希望作者以后能补充详细的内容。

    有13位网友表示赞同！

断桥残雪

我是新手小白，以前一点都不懂索引是什么？看完这篇总结，終於有点明白了！虽然还是不太理解有些复杂的概念，但基本思路已经清晰了，继续学习!

    有15位网友表示赞同！

拥抱

MySQL 索引真的太绕人了，各种类型参数看了一圈头都炸了…希望以后能出个视频教程更直观一点吧！

    有12位网友表示赞同！

爱到伤肺i

这篇总结挺好的，把 MySQL 索引的常见问题都点明了，特别是性能提升的关键点分析得很好。对实际开发有很好的指导意义。

    有10位网友表示赞同！

若他只爱我。

这个索引总结太棒了！终于不用再费劲猜想各种索引的作用了，这下明白清楚又简单啊!

    有17位网友表示赞同！

巷口酒肆

索引类型选择确实是个难题，这篇文章列举了一些常见的应用场景，很有帮助。希望能再多分享一些实践经验和案例分析，加强对理解的加深。

    有14位网友表示赞同！

呆檬

MySQL 虽然操作很方便但问题一旦出现，查起来真是难找入口…幸好发现了这篇总结！让我明白为啥数据库经常慢速的原因了，看来以后要好好学习索引才行!

    有6位网友表示赞同！

清原

我一直在尝试优化 MySQL 数据库的查询效率，这篇文章提供的索引技巧让我受益匪浅！尤其是对 B+树索引的讲解，深入浅出，真的很有帮助。

    有10位网友表示赞同！

醉红颜

虽然这篇文章总结了比较多的索引类型，但我对全文本搜索索引还是不太懂，希望能写一篇专门介绍全文本搜索索引的文章，详细解释一下它的原理和使用方法

    有19位网友表示赞同！

水波映月

我做的一款线上项目最近因为数据量太大导致 MySQL 数据库性能问题特别严重，看了这篇总结后决定重点研究下索引优化方案！希望可以有效提升数据库的查询速度。

    有11位网友表示赞同！

毒舌妖后

有时候感觉索引优化真的就是一场博弈呀，找到合适的索引类型才能最大化效率！这篇文章提醒了我这一点!

    有16位网友表示赞同！

良人凉人

这篇文章读起来比较枯燥，建议增加一些案例分析和图示说明，这样更直观易懂。毕竟学习技术最重要的就是实践！

    有8位网友表示赞同！

陌颜幽梦

我感觉对 MySQL 索引的理解还是比较肤浅，需要多做练习才能掌握这种“神功”! 不过这篇文章给我的启发不少! 以后继续学习!

    有11位网友表示赞同！

各自安好ぃ

对于初学者来说，这篇总结能提供一定的入门知识点，但是一些专业词汇还是需要查阅其他资料才能理解。

    有7位网友表示赞同！

﹎℡默默的爱

总体来说，这篇文章对 MySQL 的索引总结比较全面，特别是对于常见的索引类型分析都很详细。希望作者可以继续更新文章内容，涵盖更多的实用技巧！

    有16位网友表示赞同！