在各种ORM的文档中，它们总是提供一种创建索引的方法，等等.它们总是提到要确保创建适当的索引以提高效率，就好像这是需要使用ORM的非手工编写的SQLer的固有知识.我对索引(PK之外)的理解基本上是:如果您计划根据某列的内容进行LIKE次查询(即搜索)，则应该对该列使用全文索引.关于索引(主要是关于效率)，我还应该知道什么？我觉得在我的门口台阶上有一个知识的世界，但它下面塞着一个巨大的折叠鼠标垫，所以我走不过go (我不知道为什么我觉得我需要这么说，但谢谢你提供了沙发).
在各种ORM的文档中，它们总是提供一种创建索引的方法，等等.它们总是提到要确保创建适当的索引以提高效率，就好像这是需要使用ORM的非手工编写的SQLer的固有知识.我对索引(PK之外)的理解基本上是:如果您计划根据某列的内容进行LIKE次查询(即搜索)，则应该对该列使用全文索引.关于索引(主要是关于效率)，我还应该知道什么？我觉得在我的门口台阶上有一个知识的世界，但它下面塞着一个巨大的折叠鼠标垫，所以我走不过go (我不知道为什么我觉得我需要这么说，但谢谢你提供了沙发).
把一个索引大致想象成书后面的索引.这是一个与书中内容完全不同的区域，如果你想寻找某个特定的值，你可以go 索引中查找(索引是有序的，所以在那里查找内容比扫描书中的每一页要快得多).
索引条目有页码，因此您可以快速转到查找主题的页面.数据库索引非常类似；它是数据库中相关信息(索引中包含的字段)的有序列表，其中包含数据库查找匹配记录的信息.
所以当你有需要经常搜索的信息时，你会创建一个索引.普通索引对"部分"查找之类的查询没有帮助，但当您需要获得一组字段X具有特定值的结果时，它们可以防止DBMS需要"扫描"整个表，寻找匹配的值.
当需要对列进行排序时，它们也会有所帮助.
另一件要记住的事情是，如果DBMS允许您创建具有多个字段的单个索引，请务必针对您的DBMS调查这样做的影响.包含多个字段的索引可能只有在查询中使用所有这些字段时才完全(或根本)有用.相反，单个表有多个索引，每个索引有一个字段，对于按多个字段过滤/排序的查询可能没有太多(或任何)帮助.
您提到了全文索引和PKS(主键).这些索引与常规索引不同，尽管它们通常具有相似的用途.
首先，请注意，主键通常是一个索引(在MSSQL中，实际上是一个"聚集索引")，但这不需要特别说明.例如，MSSQL PK默认为聚集索引；聚集索引的特殊之处在于，它们不是存储在其他地方的独立数据位，而是数据本身按照聚集索引的顺序排列在表中.这就是为什么一个流行的PK是一个int的值，是自动生成的顺序，增加值.因此，聚集索引按照字段的值对表中的数据进行分类.将其与传统词典进行比较；条目本身是按"键"排序的，键是被定义的词.
但是在MSSQL(查看DBMS文档以获取信息)中，如果愿意，可以将聚集索引更改为不同的字段.有时这是在datetime个字段上完成的.
全文索引完全是不同种类的野兽.它们使用一些相同的原则，但它们所做的与我描述的普通索引不完全相同.另外:在某些DBMS中，LIKE个查询使用全文索引；需要特殊的查询操作符.
这些索引不同，因为它们的目的不是根据列的整个值(一个数字、一个日期、一小段字符数据)进行查找/排序，而是查找正在索引的文本字段中的单个单词/短语.
它们还经常能够搜索相似的词、不同的时态、常见的错误拼写等，并且通常忽略干扰词.它们的工作方式不同，这就是它们可能还需要不同的操作员来使用它们的原因.(同样，请判断您的DBMS的本地文档！)