小编Tec*_*270的帖子

这个问题今天出现了。当您将接受空值的列添加到表的末尾时，究竟会发生什么？表是否完全重建，类似于更改列顺序时发生的情况？

我一直在查看服务器的内存使用情况，并在深入研究细节时发现了一些奇怪的东西。一个索引占用了大约 15GB 的缓冲池。这恰好是整个索引的大小。关于这个特定索引的更多说明：

• 它不是复合索引。只包含一个字段
• 该字段的基数相对较低（55 个不同的值）
• 索引存在于一个有 50 亿条记录的表上
• sys.dm_db_index_usage_stats DMV 显示了 51 个组合的 user_scans 和 user_seeks
• sys.dm_db_index_usage_stats DMV 还显示了 1,159,987 个 user_updates

引出几个问题：

1. 为什么这个很少使用的索引会在缓冲池中占用如此多的空间？
2. 与低数量的扫描和搜索相比，高数量的 user_updates 不是由于维护开销而使其成为删除的候选者吗？
3. 应该首先索引具有如此低基数的字段吗？
4. 是从缓冲池中清除它以删除和重新创建的唯一方法吗？在生产机器上清除整个缓存或缓冲池显然是不可能的

我是一名试图成为 DBA 的开发人员，所以请耐心等待；)

日志文件一直很小（约 500MB），直到晚上 11 点左右，然后它开始增长，直到没有可用的磁盘空间。日志文件在上午 12:39 达到最大大小，因此增长发生在大约一个半小时的时间范围内。存储日志的驱动器只有大约 40GB 的可用空间，因此日志文件只能增长到 40GB。这应该足够了，因为数据相当静态，总共只有大约 50GB。这里还有一些额外的注意事项：

• 数据库恢复模型已满
• 每 15 分钟进行一次事务日志备份
• 晚上 11 点调用碎片整理作业，但查看历史记录，它最多只运行几分钟

我怎样才能查明造成这种情况的确切原因？它必须是一个开放的大交易，但我如何确定呢？