我在SP中的代码行很长，表现很差。此sp需要我多次验证来自同一表的多个select语句的数据。
先将数据从物理表转储到临时表是个好主意，还是可以在同一SP的多个select语句中多次引用它？
答案 0 :(得分：0)
根据您的描述，您希望提高性能。您能否向我们展示您的SP脚本和执行计划？这样我们才能有一个正确的方向并进行测试。
有一些简单但有用的技巧和优化可以提高存储过程的性能。
使用SET NOCOUNT ON
使用标准过程名称
sp_executesql而不是对动态查询执行
使用IF EXISTS和SELECT
避免将用户存储过程命名为sp_procedurename。
尽可能使用基于集合的查询。
使交易简短明了
有关更多详细信息，您可以参考它：https://www.sqlservergeeks.com/improve-stored-procedure-performance-in-sql-server/
如果您认为它不满足您的要求，请与我们分享更多信息。
最好的问候
瑞秋
答案 1 :(得分：0)
先将数据从物理表转储到临时表是个好主意，还是可以在同一SP的多个select语句中多次引用它？
如果它是本地临时表，则使用此存储过程的每个会话都会为自己创建一个单独的临时表，尽管这会减轻原始表的权重，但会增加内存和tempdb的使用。
如果这是一个全局临时表，我们只能为所有会话创建一个表，那么我们将需要在有人使用它之前手动创建一个表，如果没有用，则将其删除。
对我来说，我将使用索引视图https://docs.microsoft.com/en-us/sql/relational-databases/views/create-indexed-views?view=sql-server-2017
答案 2 :(得分：0)
没有细节很难回答。但是，由于SP如此之大而表如此之小，因此特定的选择或联接很可能会变慢，而不仅仅是反复击中该表（SQL Server非常乐意将表或索引的某些位缓存在内存中）。
如果可能，您可以获得SP各个部分的执行计划吗？或记录一些时间？还是运行统计信息？
这会告诉您哪一点比较慢，我们可以帮助您进行修复。