Ozk*_*kan 0 index foreign-key sql-server clustered-index nonclustered-index
我不是 DBA，如果这个问题听起来很愚蠢，请原谅。希望我能从有经验的 DBA 那里得到帮助，因为我对此质疑了很长时间。
假设有2张表，一张表有很多记录，一张表只是静态数据有2条记录（例如：是/否表）。
以这两个表为例：
Table_Yes_No（只有 2 条记录：Yes和No。当然，它们有一个递增的聚集 PK）Table_Form（非常大的表，有很多记录，一列有 FK 到 PK Table_Yes_No）。现在我的问题; 是否值得把一个指标的FK（参考从Table_Form该Table_Yes_No表）？该列将仅包含1或2（但未排序，因为没有索引）。是否值得索引这样的 FK？
SQLFiddle 中的一个例子：http ://sqlfiddle.com/#!18/51614/3/0
无论如何都会查询该列，问题是索引是否有助于性能。小表是静态数据，永远不会改变。大表会被大量查询，上面也会有很多CRUD。
不。
不，并且添加索引可能会损害性能。
影响是否使用二级/非聚集索引的重要因素是它的选择性（以及您尝试执行的搜索）。Y/N 有两个值 - 它的选择性能力将取决于 Y 与 N 的比例。如果它们被均匀分割，并且 Y/N 与聚集索引没有韵律/原因，它们将没有选择性，查询优化器几乎总是会忽略该索引。
如果您对较大的表发出删除操作或针对该 Y/N 列进行更新，则可能会出现速度减慢的情况。没有有效的方法来更新二级索引，因为它是由 Y/N 组织的 - 所以唯一的选择是基本上扫描整个索引以查找要更新/删除的记录。根据主表中的行数和聚集索引的大小，这可能是一个问题。
如果 Y 或 N 很少，并且您需要快速定位这些记录，则可以使用过滤索引创建一个非常小的索引，该索引仅包含稀疏填充值的记录。在这种情况下，这可能是有益的，并且比传统的非聚集索引占用的空间小得多。
如果您只是想强制执行 Y/N（或其他一些易于理解的代码集），则可以通过检查约束轻松处理，这将比 FK 具有更低的开销。
ADD CONSTRAINT CK_<ColumnName>_Is_YesNo CHECK (<ColumnName> IN ('Y','N'))