关于tsql：在T-SQL中对临时表的索引的最佳使用

如果要在存储过程中创建临时表，并想在其上添加一个或两个索引，以提高针对该存储过程做出的任何其他语句的性能，最好的方法是什么？ Sybase这样说：

"表在创建索引时必须包含数据。如果创建临时表并在空表上创建索引，则Adaptive Server不会创建列统计信息，例如直方图和密度。如果在创建后插入数据行索引，则优化器的统计信息不完整。"

但是最近一位同事提到，如果我在与实际使用临时表的存储过程不同的存储过程中创建临时表和索引，则Adaptive Server优化程序将能够使用它们。

总的来说，我不喜欢package程序增加的价值，因此我实际上并没有去测试它，但是我认为我应该把这个问题放在那儿，看看是否有人还有其他方法或建议吗？

一些想法：

• 如果您的临时表太大而必须索引，那么是否有更好的方法来解决该问题？

• 您可以通过给出以下形式的优化提示来强制其使用索引(如果您确定索引是访问表的正确方法)：

  1 2 3

  SELECT * FROM   #table (index idIndex) WHERE  id = @id

如果您总体上对性能提示感兴趣，那么我在这里还回答了一些其他有关此问题的问题：

• 最喜欢的性能调整技巧
• 您如何针对特定查询优化表？

将数据放入临时表后添加索引有什么问题？

您需要注意的一件事是索引对可能同时运行的其他过程实例的可见性。

我喜欢为这类临时表(以及索引)添加一个GUID，以确保不存在冲突。这种方法的另一个好处是，您可以简单地使temp表成为真实表。

此外，请确保在存储过程运行期间需要多次查询这些临时表中的数据，否则创建索引的成本将超过选择所带来的好处。

在Sybase中，如果先创建一个临时表，然后在一个proc中使用它，则将使用该表中的100行估算来建立选择计划。 (计划是在填充表之前在过程开始时生成的。)这可能会导致对临时表进行表扫描，因为临时表只有" 100行"。调用另一个proc将导致Sybase使用实际的行数来为select构建计划，这使优化程序可以选择要使用的更好的索引。我已经看到使用此方法的显着改进，但由于有时没有区别，因此请对您的数据库进行测试。