java通过+拼接字符串导致的无效SQL，三目运算符与+运算符结合使用时需要注意了

调试代码的过程中遇到一个比较尴尬的问题，java代码中先进行sql拼接，然后再执行拼接后的sql，即一个又臭又长的字符串。设计到sql拼接的情况，我个人比较喜欢用StringBuilder拼接，毕竟使用 + 连接多个String子串的效率是较低的。不过我也是二手代码，懒得重写了，就直接在源代码基础上修改了。

之前代码的问题其实是出现在，通过JDBC从第三方数据库获取的字段为空，通过ResultSet.getString(“xxx”)方法取出来的值不是 “” ，而是 null ，所以通常用一个三目运算将 null 替换成 “” 。
例如：

resultSet.getString("LAST_UPDATE_DATE")==null?"":rs1.getString("LAST_UPDATE_DATE");

但是，我将null替换成 “” 却又出现了新的问题。将运行的sql打印出来一看，并不是期望的样子。

MapList list = db.query("...省略若干行... where LINE_LOCATION_ID ="+rs1.getString("LINE_LOCATION_ID")==null?"":rs1.getString("LINE_LOCATION_ID"));

将业务代码替换成一个简单的demo示例：

String str1 = "abc";
String str2 = "edg";
String str3 = str1+"123"==null?"":"123"+str2;

直行过后的结果为：123edg
道理很简单，+ 的优先级要大于 == ，所以先执行+运算，再执行三目运算；三目运算时为：“abc123”==null?“123edg” = “123edg”
运算符优先级可参考下图：
所以，在原业务代码中，前面的sql语句不管怎么拼接，最后执行的都是最后一个三木运算符 : 过后的字符串，当然，肯定会抛出无效SQL的异常。解决方法很简单，就是用()将三目运算符括起来，先执行三目运算，再执行sql拼接。个人更推荐使用StringBuilder拼接，涉及变量拼接时，直接多写一行，多append一次，少调次bug。