Question

从编程生涯的第一天开始，我总是被告知硬编码/魔术数字或文字都不好。人们应该避免它。我甚至在SQL Server中的存储过程中遵循了这个原则。

最近我遇到了Ian Jose的this article，这让我感到非常震惊。他在SQL Server存储过程中用证据很好地解释了这种做法的问题。 Ian已经证明了这种方法对性能的影响非常大。

请参阅Chris Hedgate的文章，了解我在阅读Ian博客时的反应。

我理解如果它是一个较小的代码片段并且硬编码值不会被多次使用，那么有些人会自由地保留它们，而不是将它们声明为变量或常量，而是使用变量或常量代替。但似乎应该在存储过程中鼓励编写硬编码？

我确实找到了similar discussion on SO，但该线程没有评估性能损失，而是讨论如何避免硬编码，甚至我曾经认为自己非常擅长的东西。但现在在阅读了Ian的博客之后，我觉得我在解决问题时增加了更多的问题。

我想请其他专家分享他们在这个主题上的经验，因为这似乎违反了基本的编程指南。这可能是因为SQL Server的设计方式吗？这不是Oracle或MySQL中的问题吗？事实上Oracle建议these 3 nice approaches以避免硬编码。

编辑：感谢大家的宝贵意见。我想请求更多的统计数据，以建设性地挑战伊恩的数字。只是得出结论，避免硬编码对性能没有那么糟糕的影响，这正是Ian所展示的。如果我要求太多并热切期待您的回复，我很抱歉。

我还在LinkedIn打开了一个帖子，因为我最初没有得到很多回复。对于与我有同样困惑的人可以参考更多信息。

Answer 1

参数更好，因为相同的计划可用于多个参数值。 SQL Server中的SP是与应用程序编写者的合同，一个计划可用于多个调用。我在SQL Server工作已经八年了，而且可能已经发生了很多变化。但是，优化器会＆＃34;嗅探＆＃34;用于优化目的的parm值。如果这个值是＆＃34;典型的＆＃34;那就太好了。不幸的是，重新编译可以随时发生，因此可以使用任何参数值。计划指南是使应用程序免受此危险影响的一种技术。也有可能还有其他技术。

Answer 2

以下是我对问题的理解：

DBMS（SQL / Oracle）中的硬编码文字确实可以提高性能。
但是，第二次执行查询时，硬编码文字会发生变化，必须重新编译，这会填满缓存。
这意味着缓存无法有效地用于其余的数据库。

所以，同时：

SELECT * FROM X WHERE Y = '123'

可能稍快：

SELECT * FROM X WHERE Y = @myVar

如果你想这样做：

SELECT * FROM X WHERE Y = '234'

DBMS将视为不同的查询。然后填充缓存，这意味着下次发出应该缓存的查询时，它会更慢。

硬编码或Magic Literals可以提高SQL Server存储过程的性能？

2 个答案: