【问题标题】:Pretty format sql in .NET code, performance?.NET 代码中漂亮的 sql 格式,性能?
【发布时间】:2009-11-05 12:49:12
【问题描述】:

编译器会优化格式化的字符串,还是该代码的运行速度会比没有以可读方式划分的字符串慢?

例如

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

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

这只是一个小例子。你知道sql有多复杂。

【问题讨论】:

标签: c# .net sql performance


【解决方案1】:

只需使用:-

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

从编译器的角度来看,这与单行解决方案相同。尽管无论如何看到编译器优化了文字字符串的串联,我都不会感到惊讶。然而,连接方法的常见问题是忘记在字符串末尾包含空格。

【讨论】:

  • 关于“@”使用的重要提示。我已经将 & 符号用于许多不同的“字符串”,但从来不知道它适用于多行的东西!
  • 请注意,使用如图所示的“@”语法,您最终会得到与原始字符串不同的字符串:回车符、换行符和额外的空格都将包括在内。所以你的字符串将是“select *\r\n from person\r\n where id = :id”。在这种情况下,这并不重要,但在某些情况下,差异很重要。
  • StackOverflow 从我之前的评论中删除了多余的空格。每个“\r\n”后面应该有五个空格。
  • @Ray:是的,IMO 可取。在调试代码并打开字符串内容的文本可视化时,您会看到所有格式都保持不变。空格的变化对 SQL 执行没有影响。
  • @kaze:与号是& 符号。 @ 符号也称为“at 符号”或“at 符号”。
【解决方案2】:

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

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

使用reflector,您可以轻松反汇编生成的二进制文件。在 Release 模式下,生成的 IL 是:

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

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

【讨论】:

    【解决方案3】:

    你可以使用

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

    【讨论】:

    • +1 让字符串“粘”到左边而不是缩进后续行。
    【解决方案4】:

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

    内联 SQL 字符串是否是一个好主意完全是另一回事......

    【讨论】:

    • 没错,但就我而言,我经常别无选择,只能使用内联 SQL,所以我只想充分利用这种情况。
    【解决方案5】:

    啊 - C# 的永恒真理之一。使用 + 连接字符串的代码或不使用 + 连接字符串的代码哪个更好?在您的情况下,答案取决于您使用的 .NET 版本。到目前为止,.NET1 只能在单个语句中优化 + 字符串。单个字符串中过多的 + 会导致性能下降,因为编译器不得不求助于创建新的字符串实例来处理额外的字符串部分。从 .NET 2 开始,架构略有变化,多个 + 语句由编译器无缝连接。

    【讨论】:

    • 感谢投反对票——不管是谁投的。请解释为什么您认为这个答案是错误的,以便每个人都可以从中学习。
    猜你喜欢
    • 1970-01-01
    • 2023-02-19
    • 1970-01-01
    • 1970-01-01
    • 2020-07-04
    • 2018-04-22
    • 2018-12-29
    • 2020-09-03
    • 2017-06-30
    相关资源
    最近更新 更多