在各种 ORM 的文档中，它们总是提供一种创建索引的方法等。它们总是提到确保创建适当的索引以提高效率，就好像这是需要的非手写 SQLer 的固有知识使用 ORM。我对索引（PK之外）的理解基本上是：如果您打算根据列的内容进行LIKE查询（即搜索），则应该对该列使用全文索引。关于索引（主要与效率有关），我还应该知道什么？感觉自己家门口有个知识的世界，但是下面塞了一个巨大的折叠鼠标垫，进不去（不知道为什么觉得有必要这么说，但是感谢您提供沙发）。
【问题讨论】：
标签： database database-indexes database-optimization
把索引想象成一本书背面的索引。它与书的内容完全分开，如果你正在寻找一些特定的价值，你可以去索引并查找它（索引是有序的，所以找到那里的东西比扫描书的每一页要快得多)。
索引条目有一个页码，因此您可以快速转到查找主题的页面。数据库索引非常相似；它是数据库中相关信息（索引中包含的字段）的有序列表，其中包含数据库查找匹配记录的信息。
所以...当您有需要经常搜索的信息时，您会创建一个索引。普通索引不能帮助您进行像 LIKE 查询这样的“部分”搜索，但是任何时候您需要获得字段 X 具有特定值的一组结果时，它们都会使 DBMS 无需“扫描”整个表，寻找匹配的值。
当您需要对列进行排序时，它们也会有所帮助。
要记住的另一件事；如果 DBMS 允许您创建具有多个字段的单个索引，请务必调查这样做的效果，具体到您的 DBMS。只有在查询中使用了所有这些字段时，包含多个字段的索引才可能完全（或根本）有用。相反，对于单个表有多个索引，每个索引一个字段，对于按多个字段进行过滤/排序的查询可能没有太大（或任何）帮助。
您提到了全文索引和 PK（主键）。这些与常规索引不同，尽管它们通常用于类似的目的。
首先，请注意主键通常是一个索引（在 MSSQL 中，实际上是一个“聚集索引”），但这并不一定是特定的情况。例如，默认情况下，MSSQL PK 是聚集索引；聚簇索引的特殊之处在于它们不是存储在别处的单独的数据位，而是数据本身在表中按聚簇索引的顺序排列。这就是为什么流行的 PK 是一个 int 值，它是自动生成的，具有连续的、递增的值。因此，聚集索引专门按字段值对表中的数据进行排序。将此与传统词典进行比较；条目本身按“键”排序，即正在定义的单词。
但是在 MSSQL 中（请查看您的 DBMS 文档以获取信息），如果您愿意，您可以将聚集索引更改为不同的字段。有时这是在基于 datetime 的字段上完成的。
全文索引完全是不同种类的野兽。他们使用一些相同的原则，但他们所做的与我所描述的普通索引并不完全相同。另外：在某些 DBMS 中，LIKE 查询不使用全文索引；需要特殊的查询运算符。
这些索引是不同的，因为它们的目的不是查找/排序列的整个值（数字、日期、一小段字符数据），而是查找文本字段中的单个单词/短语(s) 被索引。
它们通常还可以搜索相似的词、不同的时态、常见的拼写错误等，并且通常会忽略干扰词。它们工作的不同方式是为什么它们也可能需要不同的操作员来使用它们。 （再次，检查您的 DBMS 的本地文档！）
【讨论】：
此答案是 Oracle 特定的，但答案中的要点适用于大多数关系数据库系统
【讨论】：