前几天，有人告诉我 SQL Server 2016 中涉及用于报告的只读辅助数据库的一项功能是只读辅助数据库可能具有与主数据库不同的索引。我到处搜索这个，但没有发现是这种情况。事实上，微软似乎在这里表示相反的意思（以这种方式，索引类似于 2012）。
只是好奇我是否正确阅读了这篇文章；具有不同索引的只读二级数据库将提供报告选项，但我认为它们与任何版本的 SQL Server 中的 AG 组不兼容。
使用合并复制，如果订阅者在插入发生时用完某个范围的身份，则订阅者将在插入表时抛出错误，因为发布必须授予更多身份- 并且插入发生在订户。更好的做法是让发布者只是插入的接收者，但在某些环境或情况下，发布者和订阅者都可能发生插入，因此许多人扩展了范围。
我很好奇序列与此处的身份相比如何，因为我找不到任何迹象表明序列像身份字段一样受到合并复制设置的限制。
我相信 Aaron Bertrand 或其他 MVP 在序列方面非常重要，我一直在努力推动我的组织使用它们而不是身份，但这是一段漫长的旅程。
场景：我有一个带有索引的大型 OLTP 表。我在一天或更短的时间内看到许多插入、更新和删除以及大量索引碎片。在索引构建的第一天，优化器使用索引，在第二天或第三天，优化器完全跳过它。这是针对完全相同的查询。
我脑子里的问题：为什么有些查询计划会跳过索引，因为创建索引是为了帮助优化这些计划？
这篇文章的问题：优化器是否可以跳过一个高度碎片化的索引，比如我们有 10 亿条记录并建立索引的场景，然后两个小时后，所有十亿条记录都被删除，我们有五亿条新记录？
我开始认为向该表添加索引根本无济于事，因为表的性质（数据输入快，数据输出快），但只是想了解为什么有一天，优化器会在其计划中使用索引，但第二天，它不会。
假设我有一个包含 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 行中，查看每行是否不相等，但是查询优化器已经在幕后做这件事，还是最好自己做？