看到别人写 SQL 会在 where 后面写 1=1，是什么意思？

@yueyoum orm 浪费性能加了个判断，把拼好的条件的第一个 and 给 replace 了。用 1=1 的方式性能绝无问题

没有 ORM 不会用数据库

@Ixizi orm 用到最后会发现不会写 sql 了。而且复杂的 sql 用 orm 是做不到的

编程技巧而已。

@riverphoenix 拼接无问题，做好变量绑定

@wyntergreg

我知道你的意思， 就是 添加一个新 条件， 就往老条件后面 + " and " + 新条件
最后还要把 最前面的 and 去掉。

如果要判断 还有性能损失。


1 ， 在操作数据库， 有大量 IO 的情况下， 判断一个 空字符串 也能给你的程序 带来 性能担忧， 那也就不用讨论了， 我还没达到你的高度

2 ， 就算不判断， 也可以直接拼接 两个 API 罢了。 一个 初始化条件， 一个 append 其他条件



#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void append_the_fucking_condition(char* conditon, const char* other)
{
strcat(conditon, " and ");
strcat(conditon, other);
}

char* make_condition(const char* first_condition)
{
char* conditon = (char*)malloc(sizeof(char) * 512);
strcat(conditon, first_condition);
return conditon;
}



int main()
{
char* conditon = make_condition("o.operation_time>=\'2016/6/1\'");
append_the_fucking_condition(conditon, "o.operation_time<\'2016/7/28\'");

printf("%s\n", conditon);

free(conditon);
return 0;
}

@yueyoum 程序有 bug😓

这种 SQL ，我也醉了

用 1 AND 不是更方便。

这样写还有一种原因，为了 debug 起来方便。

Python 大法好

拼接 sql 很容易出问题的，竟然还有人敢这么干！

从这么多回复看来很多人要么是强迫症或者自我感觉太良，要么从来没有维护过数据库
事实上 1=1 已经几乎可以说成为了一种约定

如果需要我要手写一个复杂一些的 SQL 语句，习惯上也都会在编辑器里面的条件前面加一个 1=1 然后回车，然后每个 AND 条件写一行，最后加上分号

好处是什么呢？
你后面继续写下面的 AND 条件根本无需担心关键字和顺序
你可以随便交换两个 AND 条件（可能仅仅是为了更好看）
可以随便复制粘贴一行条件到其它位置再修改
可以随便删除一行条件包括第一个而不需要手工修正任何内容

再举另一个例子
java 或者 js 的数组都允许最后一个元素悬挂一个逗号
目的也是为了可以让多行元素来定义数组的时候，能够保持对称性，去除首尾效应
美观有时候并不是这么重要

我要是告诉你们还有 WHERE 1=2 OR 这种技巧，楼上几个有洁癖的是不是要炸

我写 SQL 一般是这样写的：

select a
,b
,c
,d
from tble
where 1=1
and xxxxx
and xxxxx

逗号都写前面，方便调试。

如果是程序里拼接，加判断当然可以。但是既然可以不加判断直接写，为什么非要多写个判断呢？

我说一个碰到的问题。项目使用 druid 做数据库连接池，自带某安全功能会校验永真条件，只要出现永真条件就不会让 SQL 跑，目的猜是为了防 SQL 注入，一般的 SQL 注入手法之一。然后问题来了， 1=1 就是一个永真条件……从安全觉度再讨论，是否不应该去建议这样拼 SQL 呢

按楼上很多人的说法，这样拼 sql 我用了 10 来年了，怎么就没出过问题呢？这是个问题。

我看是你们满眼觉得 1=1 是何等的不爽，而忽略了更为重要的事情。这才是问题。

造成 sql 注入的根本原因是用户输入参数未转义，和 1=1 有什么关系？关键在于不要直接拼接参数，而是将其用占位符表示。难道 ORM 底层的 sql 不是拼接出来的吗？

@ykrl089 拼接 SQL ，然后参数转义并 Prepared Statements 化就没问题。

我一般
WHERE 1
AND ....
AND ....
AND ....
AND ....

@SoloCompany 同意。。