【发布时间】：2012-08-12 17:35:00
【问题描述】：
在我的测试环境中，在我的 4GB 生产数据库的副本上，我存档了大约 20% 的数据，然后从 SSMS 对其进行压缩，建议最大可用空间为 20%。
结果是一个 2.7GB 的数据库，性能非常糟糕。一个特定的查询在生产中大约是 0.5 秒，现在在测试中大约是 11 秒。如果我在测试中删除查询的全文部分，执行时间大约是 2 秒。
生产和测试的实际执行计划相同。
我重建了所有索引和全文索引。性能还是差不多的。自复制以来，测试数据库中的实际内容没有发生任何变化。
关于我在哪里寻找罪魁祸首的任何想法（除了键盘后面？:)
编辑：好的，重复该过程三次，每次结果相同...但是，在我运行收缩之前，性能会下降 - 一旦我归档非活动记录。存档前 0 秒，之后 18 秒。重建一些索引后返回 7 秒。归档过程：
- 创建一个新的“存档”数据库
- 标识要删除的 3 种类型的键，将它们存储在表变量中
- 为 20 个表中的这三个键选择“归档”数据库
- 从这三个键的 20 个“实时”表中删除了行。
就是这样。归档后，当我查看执行计划时，40% 的时间花在第一个操作上，即聚集索引扫描。
我将删除此内容，并在 SQL 网站上重新发布问题并重新表述。
【问题讨论】：
-
奇怪，我唯一能想到的就是参数嗅探。你应该在 DBA 网站上问这个问题。可能会在那里获得更高质量的答案。
-
如果我们能看到有性能问题的查询可能会有所帮助
-
+1 谢谢，去那里试试。我应该跟踪所有各种 SO 站点。
-
我想知道你的表在你运行收缩后有多碎片化。
-
该脚本似乎重建了所有聚集索引。您能否发布实际的执行计划（不是某处的图片），因为我怀疑您的性能问题不是来自聚集索引。
标签： sql-server