我有个哥们写sql语句喜欢用StringBuffer，你喜欢用什么啊？

Question

我一般都用String ，哪个好点啊？

Answer 1

这不是喜好的问题，是与占多少内存有关的。
关键看你的sql是一个字符串还是多个部分拼成的，如果是一个字符串用String，多个部分拼成的就必须用StringBuffer。另外，其实多数情况下，SQL是放在.properties文件里的。

Answer 2

个人觉得还是StringBuffer要好些，可以根据条件进行SQL的拼接啊。效率要比你用+号连起来高
不过如果你的sql很固定，没有必要拼接，那就领当别论了。

Answer 3

去看下stringBuffer的源码就明白了

Answer 4

效率不一样，
StringBuffer适用于字符串本身频繁变化的情况，比如经常附加一段新字符串到原字符串上；
String适合那些定义以后不怎么变化，只是引用他的情况

Answer 5

另外使用 + 连接字符串内部也是使用 StringBuilder 连接的。写段代码 Debug 运行跟踪一下。

Answer 6

前几天正好也在研究这个问题，我把我找到的资料与你分享下：（下面是转贴的）
使用String还是StringBuffer?出于方便的考虑，我们在进行字符串的内容处理的时候往往会出现以下的代码：
        String result="";
        result+="ok";这段代码看上去好像没有什么问题，但是需要指出的是其性能很低，原因是java中的String类不可变的（immutable），这段代码实际的工作过程会是如何的呢？通过使用javap工具我们可以知道其实上面的代码在编译成字节码的时候等同的源代码是：
        String result="";
        StringBuffer temp=new StringBuffer();
        temp.append(result);
        temp.append("ok");
        result=temp.toString();短短的两个语句怎么呢变成这么多呢？问题的原因就在String类的不可变性上，而java程序为了方便简单的字符串使用方式对+操作符进行了重载，而这个重载的处理可能因此误导很多对java中String的使用。
下面给出一个完整的代码：
1. public class Perf { 
2.   public static String detab1(String s) 
3.   { 
4.     if (s.indexOf('\t') == -1) 
5.       return s; 
6.     String res = ""; 
7.     int len = s.length(); 
8.     int pos = 0; 
9.     int i = 0; 
10.     for (; i < len && s.charAt(i) == '\t'; i++)  
11.     { 
12.       res += "        "; 
13.       pos += 8; 
14.     } 
15.     for (; i < len; i++)  
16.     { 
17.       char c = s.charAt(i); 
18.       if (c == '\t') { 
19.         do { 
20.           res += " "; 
21.           pos++; 
22.         } while (pos % 8 != 0); 
23.       } 
24.       else { 
25.         res += c; 
26.         pos++; 
27.       } 
28.     } 
29.     return res; 
30.   } 
31.        
32.   public static String detab2(String s) 
33.   { 
34.     if (s.indexOf('\t') == -1) 
35.       return s; 
36.     StringBuffer sb = new StringBuffer(); 
37.     int len = s.length(); 
38.     int pos = 0; 
39.     int i = 0; 
40.     for (; i < len && s.charAt(i) == '\t'; i++)  
41.     { 
42.       sb.append("        "); 
43.       pos += 8; 
44.     } 
45.     for (; i < len; i++) { 
46.       char c = s.charAt(i); 
47.       if (c == '\t') { 
48.         do { 
49.           sb.append(' '); 
50.           pos++; 
51.         } while (pos % 8 != 0); 
52.       } 
53.       else { 
54.         sb.append(c); 
55.         pos++; 
56.       } 
57.     } 
58.     return sb.toString(); 
59.   } 
60.          
61.   public static String testlist[] = { 
62.     "", 
63.     "\t", 
64.     "\t\t\tabc", 
65.     "abc\tdef", 
66.     "1234567\t8", 
67.     "12345678\t9", 
68.     "123456789\t" 
69.   }; 
70.          
71.   public static void main(String args[]) 
72.   { 
73.     for (int i = 0; i < testlist.length; i++) { 
74.       String tc = testlist[i]; 
75.       if (!detab1(tc).equals(detab2(tc))) 
76.         System.err.println(tc); 
77.      } 
78.          
79.      String test_string = 
80.        "\t\tthis is a test\tof detabbing performance"; 
81.      int N = 5000; 
82.      int i = 0; 
83.          
84.      long ct = System.currentTimeMillis(); 
85.      for (i = 1; i <= N; i++) 
86.        detab1(test_string); 
87.      long elapsed = System.currentTimeMillis() - ct; 
88.      System.out.println("String time = " + elapsed); 
89.           
90.      ct = System.currentTimeMillis(); 
91.      for (i = 1; i <= N; i++) 
92.        detab2(test_string); 
93.      elapsed = System.currentTimeMillis() - ct; 
94.      System.out.println("StringBuffer time = "  
95.        + elapsed); 
96.    } 
97. } 
执行以上代码的结果可以看到使用StringBuffer的版本的方法比使用String版本的一般都快十倍以上（本人使用的是JDK1.4.0）,你可以执行一下看看结果到底如何。因此得到的结论是：如果你对字符串中的内容经常进行操作，特别是内容要修改时，那么使用StringBuffer，如果最后需要String，那么使用StringBuffer的toString()方法好了！也许这就是你的程序的性能瓶颈！

Answer 7

以前写代码的时候也明和的String
后面看公司里的系统,别人都用StringBuffer,问了我同事,也没说什么实质的东西,就知道这么写比较好,所以现在一直用这种方式,不仅是写SQL语句,还有其他的,需要字符串连接等功能的时候都会使用StringBuffer

Answer 8

StringBuilder 更快！！！！！！因为省去了作线程同步的开销和时间。

Answer 9

JDK 1.6 + 改为 StringBuilder 实现了。

Answer 10

如果用string和StringBuilder来拼接字符串的话StringBuilder肯定要好点
比如String str="";str=str+"aaa";
这样str就是两个对象，如果用StringBuilder就不存在这个问题了

Answer 11

俺们公司要求stringbuffer
毕竟是省点内存的

Answer 12

同意。另外现在sql都放在xml里面的比较多。
sql的开销更多在在数据库服务器那端吧？
个人认为，对数据库服务器来说，用String做sql效率最低。扯远了。

Answer 13

9楼的很详细对于要拼接的SQL用StringBuffer

Answer 14

一个sql语句就用String，如果进行拼接操作的话，还是StringBuffer吧，确实省内存。能省点尽量省点。

Answer 15

拼接我也用的string，呵呵，能占多少内存啊？

Answer 16

楼主去仔细看看string 和 stringbuffer的区别就知道了当要拼SQL语句的时候，string在对字符串进行操作的时候，都会重新产生一个对像，而stringbuffer不会，而是在原有的上面直接加上去，用append()方法当大量的字符串拼的时候，stringbuffer不会占内存些，呵呵
一般人都习惯用stringbuffer

Answer 17

string 不可变
StringBuffer可变，省内存

Answer 18

给你看段我们现在在改的stringbuffer
==================================================================
StringBuffer q = new StringBuffer(); //バッファ
String pdtnm_tableName = CssDAO.getWithDBO(GmPdtnm.TABLE_NAME); //ＰＤＴ名称テーブル名の保存

// ＰＤＴ名称DBのフィールド名称配列
String [] pdtnm_fields = new String [] {
GmPdtnm.pdtkind, GmPdtnm.cd1, GmPdtnm.cd2, GmPdtnm.cd3,
GmPdtnm.snm1, GmPdtnm.snm2, GmPdtnm.nm, GmPdtnm.entdttm,
GmPdtnm.dttm, GmPdtnm.who,
};

// Select句の作成
q.append("SELECT ");
for(int i = 0; i < pdtnm_fields.length; i++){
q.append(pdtnm_fields[i]).append(", ");
}
q.append(" CASE WHEN ").append(GmPdtnm.pdtkind).append("=").append(GmPdtnm.PDTKIND7_PDT);
q.append(" THEN LPAD(TRIM(").append(GmPdtnm.cd1).append("),2,'0') ");
q.append(" ELSE ").append(GmPdtnm.cd1).append(" END AS cd1Sort,");
q.append(" LPAD(").append(GmPdtnm.pdtkind).append(",2,'8') AS SORTKEY ");

// From句の作成
q.append(" FROM ").append(pdtnm_tableName).append(" ");

// Where句の作成
q.append(" WHERE NOT ( ").append(GmPdtnm.pdtkind).append("=").append(GmPdtnm.PDTKIND7_PDT);
q.append(" AND ").append(GmPdtnm.cd1).append("=").append(GmPdtnm.PDTKIND7_PDT).append(") ");
if (searchCondition != null) {
String searchCondition_pdtkind = (String)searchCondition.get(PdtnmScreenParams.Pdtkind);
String searchCondition_snm1 = (String)searchCondition.get(PdtnmScreenParams.Snm1);


String searchCondition_snm2 = (String)searchCondition.get(PdtnmScreenParams.Snm2);

boolean b_where = false;
// ＰＤＴ種別条件の付加
if ( searchCondition_pdtkind != null && searchCondition_pdtkind.length() > 0){
b_where = MasterCommon.EditWildCard(q, GmPdtnm.pdtkind, searchCondition_pdtkind, b_where);
}
if ( searchCondition_snm1 != null && searchCondition_snm1.length() > 0){
b_where = MasterCommon.EditWildCard(q, GmPdtnm.snm1, searchCondition_snm1, b_where);
}

if ( searchCondition_snm2 != null && searchCondition_snm2.length() > 0){
b_where = MasterCommon.EditWildCard(q, GmPdtnm.snm2, searchCondition_snm2, b_where);
}

}

// Order by句の作成
q.append("order by SORTKEY,cd1Sort");
q.append(", ").append(GmPdtnm.cd2);
q.append(", ").append(GmPdtnm.cd3);=====================================
他让我觉得stringbuffer是大便
他让我觉得string是王道
（@#……￥*（@#……￥（*）#@……

Answer 19

还是hibernate对对象做操作来的好
为了一句sql
调试个几十遍是常有的事情。
@（）#&￥（@#&）￥@

Answer 20

JRE 1.6 后 + 的字符串连接操作也是拿 StringBuilder 实现的，最后再 toString() 所以没特殊需求使用 + 就可以，性能跟 StringBuilder 差不多。所谓使用 + 浪费计算资源是老皇历了。

Answer 21

所以说技术要用新的好啊
看看那jdk1.4用stringbuffer
册~那~~
差距啊这就是

Answer 22

混杂了很多变量的话，还是stringbuffer看的清楚点

Answer 23

以前用String 看来以后得用StringBuffer

Answer 24

如果本身拼接的不是很多，那使用 string就行了。过多就得考虑性能，使用另一个了。

Answer 25

 StringBuffer要好,不过现在还是习惯用String

Answer 26

要是比较两个字符的话。。用StringBuffer比用String 快1000倍