在.NET代码中漂亮地格式化SQL，会影响性能吗？

Question

编译器是否会优化漂亮格式化的字符串，还是说相比于没有分成易读方式的字符串，该代码将运行得更慢？

例如：

string sql = 
   "select * " +
   "from person " +
   "where id = :id";

或者

string sql = "select * from person where id = :id";

这只是一个小例子。你知道SQL可以变得多么复杂。

- kaze

---

编译器会在编译程序时优化字符串，使得在执行代码时它们相等。 - Lazarus

你为什么要将答案提交为评论？ - Winston Smith

可能重复：http://stackoverflow.com/questions/627643/sql-formatting-tool - Michael La Voie

Answer 1

只需使用：

string sql = 
   @"select * 
     from person
     where id = :id";

从编译器的角度来看，这与单行解决方案相同。尽管我不会感到惊讶，如果编译器优化了文字字符串的连接方式。然而，使用连接方法时常见的陷阱是忘记在字符串末尾包含空格。

- AnthonyWJones

---

有关“@”使用的好建议。我已经在许多不同的“字符串事情”中使用了“&”，但从未知道它适用于多行内容！ - kaze

请注意，使用如上所示的“@”语法，您将得到与原始字符串不同的字符串：换行符、换行符和额外的空格都将被包括在内。因此，您的字符串将是“select *\r\n from person\r\n where id = :id”。在这种情况下，这并不重要，但在某些情况下，差异很重要。 - Ray Burns

StackOverflow移除了我之前评论中的额外空格。每个“\r\n”后面应该有五个空格。 - Ray Burns

@Ray：真实且我认为是可取的。当调试代码并打开字符串内容的文本可视化时，您会看到所有格式保持不变。空格的变化对SQL执行没有影响。 - AnthonyWJones

@kaze：& 符号是“和符号”。@ 符号只是被称为“at符号”或“at符号”。 - LukeH

@Luke：哦，我知道了，当时我大脑和手指之间的沟通不够充分。;-) - kaze

Answer 2

你可以使用一个简单的程序来测试：

Console.WriteLine("a" + "b");

使用Reflector，您可以轻松地反汇编生成的二进制文件。在发布模式下，它所生成的中间语言代码（IL）如下：

L_0000: ldstr "ab"
L_0005: call void [mscorlib]System.Console::WriteLine(string)

所以.NET会优化“漂亮格式的字符串”。

- Andomar

Answer 3

您可以使用

string s = @"SELECT *
FROM person
WHERE id = :id";

- Adriaan Stander

---

+1 表示让字符串“粘”在左侧，而不是缩进后续行。 - Kleinux

Answer 4

字符串常量在编译时折叠，因此上面的两个代码片段本质上是相同的。

然而，是否将内联SQL字符串作为一种好的做法则完全是另一个问题...

- Greg Beech

---

在我这种情况下，我经常别无选择，只能使用内联SQL，所以我想尽力而为。 - kaze

Answer 5

啊——C#中的永恒真理之一。使用+连接字符串的代码好还是不使用的代码好？在您的情况下，答案取决于您使用的.NET版本。.NET1只能优化单个语句中的+字符串到目前为止。单个字符串中太多的+会导致性能较差，因为编译器必须创建新的字符串实例来处理额外的字符串部分。从.NET 2开始，架构略有改变，编译器可以很轻松地连接多个+语句。

- Pete OHanlon

---

谢谢对我的回答进行负投票的人，请解释一下您为什么认为这个答案是错误的，这样每个人都可以从中学习。 - Pete OHanlon