假设我有一个包含 1000 条记录的表，并且我有以下查询，它将返回 7 条记录：
SELECT *
FROM MyTable
WHERE IndexedColumn > 5000
AND OtherIndexedColumn = 2
由于这两列都有最新的索引，SQL Server 可以做出假设并更快地找到值，并且两个查询都是 SARGable（理想情况下读取次数更少）。但是，假设我需要确保该值不等于另一个值，假设不同的列是 12，所以我必须添加
AND AnotherIndexedColumn <> 12
如果那是WHERE子句中的最后一条语句，SQL Server是否使用前两个WHERE语句中的SARGability来先过滤，得到7行，然后查看7行中的每一行是否不等于12，或者是否适用在<>对原始数据集的1000行的每一行？
我问的原因是因为我知道我可以使用子查询或 CTE 来执行 SARGable 过滤器的第一部分，然后在 7 行中，查看每行是否不相等，但查询是优化器已经在幕后这样做了，还是最好自己做？
场景：我有一个带有索引的繁重 OLTP 表。我在一天或更短的时间内看到了许多插入、更新和删除以及索引碎片。在索引构建的第一天，优化器使用索引，在第二天或第三天，优化器完全跳过它。这是完全相同的查询。
我脑子里的问题：为什么有些查询计划会跳过索引，因为创建索引是为了帮助优化这些计划？
这篇文章的问题：优化器是否可以跳过一个严重碎片化的索引，例如我们有10亿条记录并建立了一个索引，然后两个小时后，所有十亿条记录被删除，我们有5亿条新记录？
我开始认为向该表添加索引根本无济于事，因为表的性质（数据输入快，数据输出快），但只是想了解为什么有一天，优化器会在其计划中使用该指数，但第二天不会。
前几天，有人告诉我，SQL Server 2016 中涉及用于报告的只读辅助数据库的一个功能是只读辅助数据库可以具有与主数据库不同的索引。我到处寻找这个，但没有发现这种情况。事实上，微软似乎在这里表明了相反的方向（这种方式，索引类似于 2012）。
只是好奇我是否正确阅读；具有不同索引的只读辅助节点将提供用于报告的选项，但我不认为它们与任何版本的 SQL Server 中的 AG 组兼容。