最近在博客园上，看到经常有人误解动态 SQL 的拼接... 常见的误解有： 1. 只用 ado.net ，无法进行动态 SQL 拼接。 2. 有几个动态参数，代码的重复量就成了这些参数的不同数量的组合数，动态参数越多，重复量越大。
最近在博客园上，看到经常有人误解动态 SQL 的拼接。比如我的一篇博客文章:
评“CPQuery, 解决拼接SQL的新方法”
https://www.zheguisoft.com/staff_blogs/jacklondon_chen/2012/09-comment_on-cpquery_a_new_way_to_solve_splicing_sql
http://www.cnblogs.com/jacklondon/archive/2012/09/11/2679738.html?updated=1
众多人在回复，其中至少有三位老兄，误解了动态 SQL 的拼接。
特写此文，阐述一下其中的技巧。希望能纠正初学者的错误。
常见的误解有：
1. 只用 ado.net ，无法进行动态 SQL 拼接。
2. 有几个动态参数，代码的重复量就成了这些参数的不同数量的组合数，动态参数越多，重复量越大。
对于第二个问题，以下的错误代码为其证据(c#代码)：
if(id>0 && string.IsNullOrEmpty(name))
{
command.CommandText = "select * from t1 where id=?";
command.Parameters.Add(id);
}
if(id<=0 && !string.IsNullOrEmpty(name))
{
command.CommandText = "select * from t1 where name=?";
command.Parameters.Add(name);
}
if(id<=0 && !string.IsNullOrEmpty(name))
{
command.CommandText = "select * from t1 where id=? and name=?";
command.Parameters.Add(id);
command.Parameters.Add(name);
}
这两个问题都很好解决，给一个正确的代码例子大家看看即可：
string sql ="select * from t1 where 1=1";
if(id != null)
{
sql += " and id=?";
addParameterValue(cmd,id);
}
if(!string.IsNullOrEmpty(name))
{
sql += " and name=?";
addParameterValue(cmd,name);
}
command.CommandText = sql;
这里的技巧在于，使用了一个 "where 1=1"， 巧妙解决了后续 sql 拼接中，每行开头是否要有 "and" 的问题。而这个 "where 1=1"，并不会对数据库的索引执行，造成性能上的影响。
对参数进行排列组合，然后写各种组合的 SQL，这个思路很奇怪。问题是，很多初学者，都有这个思维习惯。本人不是计算机科班出身，不知道是否哪本教科书，是如此教导的。但很不幸的是，这个错误思维习惯广泛存在于很多人的心中。
"where 1=1" 虽是教科书中没有的小技巧，却很管用。
另外，在程序中，一般会在用户界面上让使用用户录入数字，这个数字的数值，在代码中会自动变成 string，然后尝试 string 转换成 int/long，最后送到 sql 函数里。
这里需要特别注意的是，很多人把某个特殊的数值，作为“用户无录入的默认值”，正如本文开头所写的错误代码那样：
if(id>0 && string.IsNullOrEmpty(name))
问题在于，0 是否是不正常的业务数值，代码中看不出来。不排除程序员随意指定一个数值，作为“用户无录入的默认值”，如果不巧这个默认值，有其他意义的，那就造成问题。
在数据库的理论中，没有指定的数据，是用 null 来表示的，不论是 string 还是 int/long。
这是一个很好的思路，同样可以用在这里的 sql 拼接中。因此，我们在后面的代码中，使用了这个：
if(id != null)
上述代码中，
addParameterValue(cmd,name);
是一个简单封装的函数，用来封装如下一小段代码，目的是让最后的代码，较为简捷直观：
DbParameter p = cmd.CreateParameter();
p.ParameterName = "@XXX";
p.Value = TTT;
cmd.Parameters.Add(p);
当然，这个 addParameterValue() 封装函数，是可有可无的。多写几个 DbParameter p = cmd.CreateParameter() 并没有什么大问题。只是代码的可读性较差罢了。