string sqlstr="insert into " + STORE_TABLENAME + " ("
+ STORE_CODE + ","
+ STORE_INDATETIME + ","
+ STORE_NUMBER + ","
+ STORE_PRICE + ","
+ STORE_OPERATOR + ","
+ ") select "
+ CODE+","
+ DATETIME+","
+ INOROUTNUM+","
+ PRICE+","
+ OPERATOR
+" from "+ TABLENAME
+" id="+ id;
这个字符串中,所有的大写都是常量,仅最后的小写id是一个变量
请问是不是vs编译器会将这些常量直接连接起来,而不是像下面这样,用stringbuilder能大幅度的省资源?
for(int i=0;i<100;i++)
stringbuilder.append(i.tostring());
------解决思路----------------------
你这么点字符串拼接算个啥……你要是有个几万这样的字符串+么倒是会因为大量字符串碎片会产生问题……
另外最讨厌这种命名可以一个字符串写完的，非要用加号加起来的方式，就不能用string.Format的
------解决思路----------------------
调用一次不明显
不过用string.format或者string.concat从代码可读性和优雅的方面更好。
------解决思路----------------------
没循环的话，没必要用。
------解决思路----------------------
就我个人而言，format超过6个就已经可以认为format是不是有问题了，但数数问题你还真小看了码农的能力，我见过在几百行的拼接html中，占位符达30几位的format，而且这个format还是通过复杂的逻辑得到的（这个逻辑会生成不同的html），当初真心给这个代码跪了
而看你这个代码，可以猜测你是写了一个通用的，具有同样表结构的Insert Into功能，对于这种情况，我会更偏向于定义这个方法专用的实体类（这里假定你这么做是合情合理的），然后通过反射来生成这样的一个SQL（你的前后格式都对应的，所以按规则生成SQL还是比较容易的），当然生成过程中是通过StringBuilder来拼接，减少字符串碎片
另外，你举得“上百上千个线程”例子这本身就不恰当，如果这像你这么说，那最大的可能就是：字符串碎片问题还没产生，你的电脑已经因这么多的线程出性能问题了
最后，我很有自知自明，从来不认为自己是大神，最多就是一个比你们多做了几年的码农而已……
------解决思路----------------------
而且如果你的format真的无可奈何的长，那可以给你个写法建议如下，这样相对来说可以减免掉一部分数数问题
string.Format("{0}{1}{2}{3}",obj0/*0*/,obj1/*1*/,obj2/*2*/,obj3/*3*/)------解决思路----------------------
想了下，字段用字典，表名用KeyValue传递更方便，反射反而麻烦
------解决思路----------------------
这么点，直接加吧，
------解决思路----------------------
既然是 习惯看这种格式了 那也就这样了
不就是拼装一个字符串吗？没有多大开销
只是日后需求稍稍发生变化，就会让你修改的头皮发麻。重新编译发布也是够烦人的了
------解决思路----------------------
看量的多少 如果拼得很多（几十上百个），而且也比较长，我用stringbuilding，一般情况下（比如你给的这个例子），直接用string.format或者string+string（而且这种情况下人根本察觉不到你可能缩短的那一丁点效率）
------解决思路----------------------
太短了，用不着