我正在使用HeidiSQL，并且开始研究索引，因为特别是有一张表，由于填充了1,249,848行，因此查询运行的时间明显更长。几乎每个表（有合理的例外）都有一个主键；这很简单。我看过Socratica's SQL Index视频，这对那些一般SQL经验有限的人来说是一个很棒的手表，尽管不幸的是，她未能阐明应该使用哪种类型的索引。
HeidiSQL允许至少使用MariaDB创建primary，key，unique，fulltext和spatial索引，而我一直在使用过去几年中的MariaDB。我计划添加几个索引的表用于蜘蛛日志表的date和engine列。我将DATETIME和VARCHAR()用于相应的列，因此我对要使用的索引类型有所了解，尽管我非常希望将索引与建议进行比较。该手册涵盖了什么索引，但似乎并未涵盖它们与其他索引相比最适合的数据集的对比。
答案 0 :(得分：1)
每个表上只能有一个 primary 键，并且应该始终定义一个。表数据（在磁盘上）将以快速搜索主键的方式存储。 （称为Clustered Index）
在大多数应用程序中，主键是auto_increment surrogate key。
但是您也可以选择natural primary key，它是数据中已经出现的唯一标识符，例如序列号，MAC地址，社会保险号，...
搜索主键是检索数据的最快方法，但只能有一种。
在谈论建立索引以加快搜索速度时，人们通常指的是简单的KEY，也称为“辅助键”。
对于许多用例，创建包含多个属性的“ covering index”很有用。
即KEY(lastname, surname)加快了
WHERE lastname="Anderson" AND firstname="Thomas"
之类的查询
以及
WHERE lastname="Anderson"
了解应用程序执行得最多的查询并为这些查询设计索引非常重要：
并不是每个查询都可以有效地使用索引，也不是所有索引都有用，并且在高写入负载下，拥有好几个要比许多差的好。
索引的写入成本很高：连续更新意味着每个单个索引！
其他类型是特殊的：
unique 键可确保只有一行可以包含相同的属性值。通常用于执行业务规则，例如“帐户的电子邮件地址必须唯一” /“每个电子邮件仅一个帐户”。
fulltext 只能应用于TEXT列，实际上是嵌入在数据库中的小型搜索引擎。您可以使用AND和OR条件，以及带有特殊MATCH运算符的通配符来进行文本搜索。
和 spatial 用于坐标系/几何，不能用于其他任何东西。