我正在执行我在这个网站上find的脚本来标记我所有的表和存储过程来重新编译。
（我改变它也标记存储过程）
我有一个使用大量数据表的Windows Forms（.net 3.5）应用程序，在执行这个脚本之后，打开一个数据大量的时间从8秒变成了4秒。
我必须经常运行这样的脚本吗？ 我认为SQL Server会照顾编译程序等。
顺便说一句：这个问题应该如此吗？ 我以为DBA会在SF上。
来自微软 ：
“由于在索引列中添加索引或更改数据等操作会改变数据库，因此用于访问其表的原始查询计划应该通过重新编译来再次优化，这种优化会在第一次在Microsoft之后运行存储过程时自动发生如果存储过程使用的基础表发生更改，也会发生SQL Server，但是如果添加了一个新的索引，存储过程可能会受益，那么直到下一次存储过程在Microsoft SQL之后运行时才会进行优化服务器重新启动。在这种情况下，强制存储过程在下次执行时重新编译会非常有用
强制存储过程重新编译的另一个原因是在必要时抵消存储过程编译的“参数嗅探”行为。 当SQL Server执行存储过程时，过程编译时使用的任何参数值都包含在生成查询计划的一部分中。 如果这些值代表随后调用该过程的典型值，则每次编译和执行时，存储过程都将从查询计划中受益。 如果不是，绩效可能会受到影响。“
考虑到在SQL Server中使用“编译”这个词是不同的，比如说一个普通的应用程序。 在正常的应用程序中，代码被编译为机器语言就绪状态，所以不必在运行时解释。 SQL Server使用编译是确定执行查询的最佳执行计划。 由于数据有可能不断变化，SQL Server可能不得不根据可用的索引，统计的质量等做出新的判断，这些都会影响执行计划。 因此，无论何时执行存储过程，SQL Server都会确定是否可以重新使用该查询的现有执行计划，或者是否需要生成新的执行计划。 当然，如果没有计划，就会产生一个新计划。
顺便说一句，如果你仔细想想，它与.NET应用程序所做的并没有什么不同。 .NET应用程序被编译为中间语言状态，但只在第一次运行时默认完全编译。
SP编译时，其执行path是固定的。 它不能利用新的索引或基于表格大小的不同策略。 重新编译允许它重新评估执行条件。
我在这里经验不是很丰富 – 但是经验法则是让简单的SP每次重新编译一次。 在更复杂的情况下只设置编译