我正在尝试找出提高非常慢查询性能的方法。它有更明显的问题，但我注意到的一件事是 WHERE 子句中的条件之一是 'AND t.data IS NOT NULL' 而表 t 的 'data' 列没有为 NULL 的条目并且确实有一个 NOT NULL 约束。
所以我想知道查询优化器是否能够忽略条件。我的想法是，它不能仅仅因为约束而这样做（因为不能保证它是否是用 NOVALIDATE 创建的），但可能足够“聪明”以使用有关列中 NULL 字段数量的统计信息。
我自己的测试是不确定的，我无法找到有关此主题的任何进一步信息。
我目前正在开发一个测试系统，并且由于我想要优化的查询的性质，我正在尝试尽可能模拟“冷”读取。其中一部分是在执行查询之前清除缓冲区缓存。从我可以找到的所有内容中，应该在检查点期间写入脏缓冲区页面。但是，即使在发出 CHECKPOINT 之后，缓冲池中似乎仍然有 169 个我的数据库的脏页（通过 评估SELECT * FROM sys.dm_os_buffer_descriptors WHERE database_id=7 AND is_modified=1）。
我对检查点或 sys.dm_os_buffer_descriptors 的内容有什么误解吗？如果没有，为什么我应该写掉它们之后我仍然有脏页？
我有一个包含四列和约 6.6 亿行的表格。其中两列是 bigint，尽管它们实际上并不需要包含任何不能放入 int 的内容。因此作为测试，我将它们的数据类型从 bigint 更改为 int。该表上有一个聚集索引，它的键不使用这两列。
结果令我困惑。数据空间（在表属性中）保持不变，而索引空间下降了 23.5%。有人可以向我解释那里发生了什么吗？为什么数据空间没有改变？
顺便说一句，我做了类似于另一张桌子的事情。那里的数据空间下降了 30.4%，这正是我根据行大小的变化计算得出的。索引空间的下降类似。
[编辑说明：我最初忽略了恢复一个非聚集索引。这已得到修复，问题也相应更改]