我创建了一个每晚运行的脚本，以根据碎片重建和重新组织索引，重建碎片 > 30% 的索引，重新组织碎片 10% - 30% 的索引。
运行脚本后，我注意到我们有大约 400 个索引仍然反映了 > 10% 的碎片计数，经过更多调查，我发现一些帖子提到页数 < 1000 的任何索引都不会被 SQL 重新组织.
我进一步调查了为什么我的脚本没有更新我的所有索引并发现查询的结果
sys.dm_db_index_physical_stats(DB_ID(DB_NAME()),NULL,NULL,NULL, 'DETAILED')
对于具有 > 1 条记录的表，显示页数为 5、6，record_count 列有大约 16 000 条记录，然后我通过运行强制在索引上重建索引
ALTER INDEX [indexname] ON [schema].[table] REBUILD WITH (FILLFACTOR = 85, STATISTICS_NORECOMPUTE = OFF)
我的索引现在显示 1 磨机 + 记录计数。
我的问题是：为什么重新组织他的索引不会纠正索引中的记录计数和碎片以及首先是什么导致此记录计数值在索引上变得如此过时？
我现在的计划是今晚强制重建所有索引，然后按照正常方式运行我的脚本。我是否应该担心索引记录计数再次过时？
今天我使用 Cacti 在我们的 SQL 服务器上实现了一个监控解决方案，我注意到的第一件事是临时表的数量增加了，在我们的测试系统上仅仅 3 小时内，我们在临时数据库中增加了 300 多个临时表。我还注意到 SQL Server 在这 3 小时内的内存增长是巨大的 - 3 小时后使用了 15 GB。
当我运行 SP_WHO 时，只有 3-4 个用户在测试系统上进行测试，并且向应用程序打开了大约 5 个连接。
什么可能导致这种情况？我对临时数据库中的对象进行了查询，所有名称都与 #XXXXXXXXX 类似，我在某处读到这些来自表变量（声明 @myTable...）
有什么方法可以检查为什么我们的临时表数量会增加以及是什么原因造成的？在此阶段的任何帮助将不胜感激。
我明天将安装 2008 年的服务包，希望能解决问题。