Sql 索引varchar列

我问过谷歌，但我还是很困惑

1） 为Varchar列编制索引时是否存在问题。当我不应该，当我应该

2） 索引char列与Varchar列

---

谢谢

1-如果您正在查询它，并且它具有足够的选择性，请为它编制索引。如果它是一个90%的值都相同的列，那么就没有什么意义了

这不是一个问题，但我猜你想知道你是否应该这样做。是的，如果您查询它并且它满足上述条件。

一般性能

在理论/设计中，您有一个逻辑模型，比如用户名是唯一的

然而，在实现时，您知道，与使用代理“userid”列（作为索引更有效）相比，使用它是昂贵的（大小写、重音、长度等）。也就是说，无论如何，您都会在名称上有一个索引，因为它应该是唯一的

不同之处在于使用此索引的位置：如果它作为外键列位于子表中，则这不是一个好主意。或作为聚集索引

作为没有FKs的表的单个索引，它既不在这里也不在那里

最后，我只想将char/varchar用于ISO语言或货币代码（DE、EN、GBP、CHF等）。但老实说，我的截止日期各不相同……

• 广告1）是的，900字节的限制，巨大的键，大量的索引页，大量的I/O，低效的索引操作。结论：除非您的

  varchar

  最大值约为50个字符，否则不要这样做
• 广告2）与广告1相同。

  char

  与

  varchar

  之间的真正区别是固定大小与可变大小（即

  char（100）

  ）在数据页中总是占用100字节，

  varchar（100）

  最多占用100字节）

---

事实上，索引（N）varchar列工作正常。唯一的问题是要注意900字节的宽度限制varchar（max）和nvarchar（max）存在索引问题，这就是为什么不应该使用它们，除非您打算溢出普通varchar和nvarchar字段的大小。您不能单独在nvarchar（max）或varchar（max）上创建索引。它可以是另一个索引的一部分，但不能是索引的主要查找部分。这些数据类型仅用于大块数据，而不用于需要索引的字段类型。许多人认为使用它们比花时间正确调整列的大小更容易，然后它们会得到一个不可索引的混乱和一个比slug慢的数据库。引用在线书籍：“大对象（LOB）数据类型的列：ntext、text、varchar（max）、nvarchar（max）、varbinary（max）、xml或图像不能指定为索引的键列。“@HGLEM-当我考虑它时，这是有道理的（为什么它们不可索引），但我没有意识到这是一个约束。谢谢你提供的信息。如果你能支持一个现有的答案，或者有什么要补充的，请这样做。