`

低效的where 1=1

 
阅读更多
 
  也许很多人在开发多条件查询或模糊查询的时候，为保证不管选择哪种过滤条件总保证查询条件为true，于是在where子句后选择1=1或者0=0技巧来满足模糊查询。当然这的确对开发人员来说是一个不错的技巧。于是我在Mysql中通过上千万条的数据测试发现很耗性能。即便是建了常用字段的索引(排序)也没有作用，足以确定1=1很低效，大数据量很耗性能。

  select * from t_user where 1=1

   因为添加了"1=1"的过滤条件以后数据库系统无法使用索引等优化查询策略，数据库系统将会被迫对每行数据进行扫描(也就是全表扫描)来比较此行是否满足顾虑条件，当表中数据量比较大的时候查询速度会非常慢。


--------------------
maoone2003的回答甚是不错(红色部分) 作为开题人 我采纳...

select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table，这个SQL语句很明显是全表扫描，需要大量的IO操作，数据量越大越慢，建议查询时增加必输项，即where 1=1后面追加一些常用的必选条件，并且将这些必选条件建立适当的索引，效率会大大提高
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题

分享到：
| 动态代理-实现操作对象和业务对象解耦
评论
41 楼 duesouth 2010-07-12  
在公司DB上做了一个例子，sybase系统，打出了query plan

select count(*) from order_header
231835 rows
=============================================================
select * from order_header

QUERY PLAN FOR STATEMENT 1 (at line 1).




    STEP 1
        The type of query is SELECT.


        FROM TABLE
            order_header
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 32 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.


Server Message:  Number  3630, Severity  10
Server 'DEVELOP', Line 1:
Total estimated I/O cost for statement 1 (at line 1): 178628.


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.

Execution Time 0.
SQL Server cpu time: 0 ms.  SQL Server elapsed time: 0 ms.
=============================================================
select * from order_header where 1=1
QUERY PLAN FOR STATEMENT 1 (at line 1).




    STEP 1
        The type of query is SELECT.


        FROM TABLE
            order_header
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 32 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.


Server Message:  Number  3630, Severity  10
Server 'DEVELOP', Line 1:
Total estimated I/O cost for statement 1 (at line 1): 178628.


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.

Execution Time 0.
SQL Server cpu time: 0 ms.  SQL Server elapsed time: 0 ms.


结论：1.两种情况都是table scan
      2.两种情况IO一样
      3.1=1的写法应该不会影响效率
40 楼 duesouth 2010-07-12  
maoone2003 写道
select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table，这个SQL语句很明显是全表扫描，需要大量的IO操作，数据量越大越慢，建议查询时增加必输项，即where 1=1后面追加一些常用的必选条件，并且将这些必选条件建立适当的索引，效率会大大提高
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题


select * from table where 1=0 呢 ? 也等效于select * 吗？
39 楼 sunwenran 2010-07-12  
这个例子太邪恶了。
s+=s;
俺还以为s+="a"

StringBuilder还是要出错啊。OutOfMemoryError必须滴
38 楼 maozj 2010-07-12  
maoone2003 写道
select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table，这个SQL语句很明显是全表扫描，需要大量的IO操作，数据量越大越慢，建议查询时增加必输项，即where 1=1后面追加一些常用的必选条件，并且将这些必选条件建立适当的索引，效率会大大提高
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题

-------------------
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题
很赞成
37 楼 xiaojing3517 2010-07-12  
nanquan 写道
xiaojing3517 写道
superyang 写道
抛出异常的爱 写道
 
StringBuffer buffer = new StringBuffer("select * from T where 1=1 ");
for(Map.Enty e : map){
    buffer .appand ("and "+ e.getKey()+" = '"+e.getValue()+"'");
}





		String hql = "select e.id,e.name,e.provice,e.city,e.total,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id";

		if (!this.isNull(email_type)) {

			hql += " and e.name like '%" + email_type + "%'";
		}
		if (!this.isNull(provice)) {

			hql += " and e.provice like '%" + provice + "%'";
		}
		if (!this.isNull(city)) {

			hql += " and e.city like '%" + city + "%'";
		}
		if (!this.isNull(name)) {

			hql += " and e.name like '%" + name + "%'";
		}
		if (!this.isNull(add_admin_id)) {

			hql += " and e.adminByAddAdminId.id='" + add_admin_id + "'";
		}
		if (!this.isNull(order_type)) {

			String arr[] = order_type.split("_");
			hql += " order by e." + arr[0] + " " + arr[1];
			hql += ",e.addtime desc";
		} else {
			hql += " e.addtime desc";
		}


这样写可不可以??
为什么很多人用StringBuffer的..???

莫非这位大锅您用的String？ 
String s = "a";
    for(int i=0;i<50;i++){
        s+=s;
        System.out.println(i);
    }

可以简单走一下。你会发现在不改变jvm内存的情况下，第20次会出现什么

爷们 你可以用StringBuilder试一下你的例子 这个例子中拼装的字符串的量是巨大的 循环到20几的时候 已经是千万级的了! 虽然StringBuilder/StringBuffer拼装字符串上是有很大的优势 但这个例子有些牵强了

String、StringBuffer。笑而不语
36 楼 maozj 2010-07-12  
maoone2003 写道
select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table，这个SQL语句很明显是全表扫描，需要大量的IO操作，数据量越大越慢，建议查询时增加必输项，即where 1=1后面追加一些常用的必选条件，并且将这些必选条件建立适当的索引，效率会大大提高
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题

----------------------------------------------

select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table

等效？
35 楼 nanquan 2010-07-12  
xiaojing3517 写道
superyang 写道
抛出异常的爱 写道
 
StringBuffer buffer = new StringBuffer("select * from T where 1=1 ");
for(Map.Enty e : map){
    buffer .appand ("and "+ e.getKey()+" = '"+e.getValue()+"'");
}





		String hql = "select e.id,e.name,e.provice,e.city,e.total,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id";

		if (!this.isNull(email_type)) {

			hql += " and e.name like '%" + email_type + "%'";
		}
		if (!this.isNull(provice)) {

			hql += " and e.provice like '%" + provice + "%'";
		}
		if (!this.isNull(city)) {

			hql += " and e.city like '%" + city + "%'";
		}
		if (!this.isNull(name)) {

			hql += " and e.name like '%" + name + "%'";
		}
		if (!this.isNull(add_admin_id)) {

			hql += " and e.adminByAddAdminId.id='" + add_admin_id + "'";
		}
		if (!this.isNull(order_type)) {

			String arr[] = order_type.split("_");
			hql += " order by e." + arr[0] + " " + arr[1];
			hql += ",e.addtime desc";
		} else {
			hql += " e.addtime desc";
		}


这样写可不可以??
为什么很多人用StringBuffer的..???

莫非这位大锅您用的String？ 
String s = "a";
    for(int i=0;i<50;i++){
        s+=s;
        System.out.println(i);
    }

可以简单走一下。你会发现在不改变jvm内存的情况下，第20次会出现什么

爷们 你可以用StringBuilder试一下你的例子 这个例子中拼装的字符串的量是巨大的 循环到20几的时候 已经是千万级的了! 虽然StringBuilder/StringBuffer拼装字符串上是有很大的优势 但这个例子有些牵强了
34 楼 maoone2003 2010-07-12  
select * from table where 1=1因为table中根本就没有名称为1的字段，所以该SQL等效于select * from table，这个SQL语句很明显是全表扫描，需要大量的IO操作，数据量越大越慢，建议查询时增加必输项，即where 1=1后面追加一些常用的必选条件，并且将这些必选条件建立适当的索引，效率会大大提高
PS：这不是SQL写法的问题，也不是数据库的问题，是自己程序逻辑的问题
33 楼 Das_flamen 2010-07-12  
superyang 写道
抛出异常的爱 写道
 
StringBuffer buffer = new StringBuffer("select * from T where 1=1 ");
for(Map.Enty e : map){
    buffer .appand ("and "+ e.getKey()+" = '"+e.getValue()+"'");
}





		String hql = "select e.id,e.name,e.provice,e.city,e.total,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id";

		if (!this.isNull(email_type)) {

			hql += " and e.name like '%" + email_type + "%'";
		}
		if (!this.isNull(provice)) {

			hql += " and e.provice like '%" + provice + "%'";
		}
		if (!this.isNull(city)) {

			hql += " and e.city like '%" + city + "%'";
		}
		if (!this.isNull(name)) {

			hql += " and e.name like '%" + name + "%'";
		}
		if (!this.isNull(add_admin_id)) {

			hql += " and e.adminByAddAdminId.id='" + add_admin_id + "'";
		}
		if (!this.isNull(order_type)) {

			String arr[] = order_type.split("_");
			hql += " order by e." + arr[0] + " " + arr[1];
			hql += ",e.addtime desc";
		} else {
			hql += " e.addtime desc";
		}


这样写可不可以??
为什么很多人用StringBuffer的..???

你可以去试下，StringBuffer的效率不是String能比的，拼接的时候String多了严重影响性能。当然，如果就几条那也没什么，不过强烈推荐不要用String，不是个好习惯。
32 楼 xiaojing3517 2010-07-12  
superyang 写道
抛出异常的爱 写道
 
StringBuffer buffer = new StringBuffer("select * from T where 1=1 ");
for(Map.Enty e : map){
    buffer .appand ("and "+ e.getKey()+" = '"+e.getValue()+"'");
}





		String hql = "select e.id,e.name,e.provice,e.city,e.total,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id";

		if (!this.isNull(email_type)) {

			hql += " and e.name like '%" + email_type + "%'";
		}
		if (!this.isNull(provice)) {

			hql += " and e.provice like '%" + provice + "%'";
		}
		if (!this.isNull(city)) {

			hql += " and e.city like '%" + city + "%'";
		}
		if (!this.isNull(name)) {

			hql += " and e.name like '%" + name + "%'";
		}
		if (!this.isNull(add_admin_id)) {

			hql += " and e.adminByAddAdminId.id='" + add_admin_id + "'";
		}
		if (!this.isNull(order_type)) {

			String arr[] = order_type.split("_");
			hql += " order by e." + arr[0] + " " + arr[1];
			hql += ",e.addtime desc";
		} else {
			hql += " e.addtime desc";
		}


这样写可不可以??
为什么很多人用StringBuffer的..???

莫非这位大锅您用的String？ 
String s = "a";
    for(int i=0;i<50;i++){
        s+=s;
        System.out.println(i);
    }

可以简单走一下。你会发现在不改变jvm内存的情况下，第20次会出现什么
31 楼 superyang 2010-07-12  
抛出异常的爱 写道
 
StringBuffer buffer = new StringBuffer("select * from T where 1=1 ");
for(Map.Enty e : map){
    buffer .appand ("and "+ e.getKey()+" = '"+e.getValue()+"'");
}





		String hql = "select e.id,e.name,e.provice,e.city,e.total,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id";

		if (!this.isNull(email_type)) {

			hql += " and e.name like '%" + email_type + "%'";
		}
		if (!this.isNull(provice)) {

			hql += " and e.provice like '%" + provice + "%'";
		}
		if (!this.isNull(city)) {

			hql += " and e.city like '%" + city + "%'";
		}
		if (!this.isNull(name)) {

			hql += " and e.name like '%" + name + "%'";
		}
		if (!this.isNull(add_admin_id)) {

			hql += " and e.adminByAddAdminId.id='" + add_admin_id + "'";
		}
		if (!this.isNull(order_type)) {

			String arr[] = order_type.split("_");
			hql += " order by e." + arr[0] + " " + arr[1];
			hql += ",e.addtime desc";
		} else {
			hql += " e.addtime desc";
		}


这样写可不可以??
为什么很多人用StringBuffer的..???
30 楼 superyang 2010-07-12  
maozj 写道
superyang 写道
好像是很低效,一个邮件收集系统才10万多条数据就已经变得很慢了,也查不出是什原因..(mysql5.0) 


以前是这样的hql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),e.admin.name,date_format(e.sendtime,'%Y-%m-%d') from email e where 1=1;

现在改为这样native-sql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id
也是很慢.


---

select count(e.id) from email e where 1=1



查询到数据量为5万多,点分页就快一点.
查询全部数据量,点分页就相当慢.

很欣慰你的细腻



能分析一下是什么问题?
能解决吗?

赏分:100分...
29 楼 whitesock 2010-07-12  
maozj 写道



看成本...这是SqlServer中的测试

如果去掉where 1=1
成本为0%


这就不用全表扫描了？除非有在所有列上有covering index。
28 楼 maozj 2010-07-12  
superyang 写道
好像是很低效,一个邮件收集系统才10万多条数据就已经变得很慢了,也查不出是什原因..(mysql5.0) 


以前是这样的hql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),e.admin.name,date_format(e.sendtime,'%Y-%m-%d') from email e where 1=1;

现在改为这样native-sql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id
也是很慢.


---

select count(e.id) from email e where 1=1



查询到数据量为5万多,点分页就快一点.
查询全部数据量,点分页就相当慢.

很欣慰你的细腻
27 楼 superyang 2010-07-12  
好像是很低效,一个邮件收集系统才10万多条数据就已经变得很慢了,也查不出是什原因..(mysql5.0) 


以前是这样的hql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),e.admin.name,date_format(e.sendtime,'%Y-%m-%d') from email e where 1=1;

现在改为这样native-sql:
select e.id,e.name,date_format(e.addtime,'%Y-%m-%d'),a.name,date_format(e.sendtime,'%Y-%m-%d') from email e,admin a where e.add_admin_id=a.id
也是很慢.


---

select count(e.id) from email e where 1=1



查询到数据量为5万多,点分页就快一点.
查询全部数据量,点分页就相当慢.


请问一下:哪里出问题了??
26 楼 maozj 2010-07-12  



看成本...这是SqlServer中的测试

如果去掉where 1=1
成本为0%
25 楼 icefishc 2010-07-12  
maozj 写道
seanzeng 写道
我刚试了 postgresql 和 oracle。

这个1=1根本不会处理，直接过滤了，该用索引的还是用索引。

不知道你测试的时候用的是什么样的环境和SQL语句？



1. 插入10000000条数据到mytable
2. 比较： select * from mytable
          select * from mytable where 1=1
3. 看看执行时间

把查询计划帖出来吧
24 楼 liudun 2010-07-12  
willko 写道
Mysql有查询优化器，像这种直接过滤了。。


我印象中也是这样的。哪个数据库这么弱智，1=1、2=2这种明显的占位条件都不知道去掉吗？
23 楼 silasoni 2010-07-12  
Mysql有查询优化器可以直接过滤where 1=1
那优化过程再短不也是消耗时间么
求教
22 楼 maozj 2010-07-12  
即便用到索引 也不会用到其优化性
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    海量数据处理

    在 WHERE 子句中直接使用 `IS NULL` 或 `IS NOT NULL` 进行判断会导致数据库引擎放弃使用索引而执行全表扫描，这在大数据量的情况下极为低效。例如： ```sql -- 不推荐的做法 SELECT id FROM t WHERE num IS NULL; ...

    Oracle SQL 性能优化

    - **低效查询**：`SELECT TAB_NAME FROM TABLES WHERE TAB_NAME = (SELECT TAB_NAME FROM TAB_COLUMNS WHERE VERSION = 604) AND DB_VER = (SELECT DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)` - **高效查询**：...

    基于.net_的大数据量SQL_SERVER_系统_数据库和代码_优化方案

    1. **避免全表扫描**：全表扫描意味着数据库引擎需要遍历表中的每一行数据来查找满足条件的记录，这对于大数据量的应用来说是非常低效的。为了减少全表扫描的次数，我们需要充分利用索引的优势。 2. **合理利用索引*...

    查询优化技巧三十则

    SELECT num FROM a WHERE EXISTS (SELECT 1 FROM b WHERE num = a.num); ``` #### 14. 减少字符串操作 在查询条件中过多地使用字符串操作（如 `UPPER`, `LOWER`）可能导致索引无法被利用。 #### 15. 限制返回的...

    处理百万级以上的数据查询提高效率的办法

    SELECT col1, col2 INTO #t FROM t WHERE 1 = 0; ``` - **正确做法**（创建空表）： ```sql CREATE TABLE #t (col1 datatype, col2 datatype); ``` #### 12. 优化子查询的使用 子查询可能导致性能下降，特别...

    SQL Server SQL优化

    - **推荐做法**：在可以接受脏读的情况下使用`WITH (NOLOCK)`，如`SELECT TOP 1 * FROM A WITH (NOLOCK) WHERE state = 1`。 - **不推荐做法**：直接使用`SELECT TOP 1 * FROM A WHERE state = 1`，可能导致长时间...

    数据查询优化技巧三十则

    10. **避免无用的查询结构**：如`SELECT col1, col2 INTO #t FROM t WHERE 1 = 0;`这类查询不返回任何行，但会浪费系统资源。 11. **使用`EXISTS`代替`IN`**：在大多数情况下，`EXISTS`比`IN`更高效，因为`EXISTS`...

    Oracle SQL性能优化技巧总结

    如果`tab1`作为基础表，则需要对所有记录进行处理，这显然是低效的。 - 高效示例： ```sql SELECT COUNT(*) FROM tab1, tab2; ``` 将记录数较少的`tab2`作为基础表，可以显著提高查询速度。 - **扩展**：当...

    数据库查询效率

    - **优化技巧**：对于连续的数值查询，推荐使用BETWEEN替代IN，如 `SELECT id FROM t WHERE num BETWEEN 1 AND 3`。 **5. LIKE操作符的优化** - **问题说明**：使用LIKE进行模式匹配时，特别是前导通配符（如 `%abc...

    Oracle-SQL优化(内部资料).docx

    - 方法1（最低效）：分别执行两次查询。 - 方法2（次低效）：使用游标执行两次查询。 - 方法3（高效）：使用一个查询同时获取所需的信息。 此外，还可以通过调整SQL工具中的ARRAYSIZE参数来增加每次数据库访问的...

    access分页实现 源代码

    SELECT TOP pagesize * FROM table WHERE 1=1 condition sort; ``` 其中`condition`和`sort`会在实际执行时根据传入的参数动态拼接。 2. **非首页面查询**：对于非首页面，查询逻辑相对复杂。首先，需要获取前...

    MySQL性能优化的最佳实践

    SELECT 1 FROM users WHERE username = '中国' LIMIT 1; ``` #### 五、合理使用索引 **4. 为搜索字段建索引** 除了主键和唯一字段外，还可以为经常用于搜索的字段创建索引。例如，如果经常需要按`last_name`字段...

    Java中Oracle操作绑定变量使用用户工具模块解决方案

    StringBuffer sql = new StringBuffer("SELECT id, name, department, leader FROM employee WHERE 1=1"); if (name != null && name.trim().length() &gt; 0) { sql.append(" AND name='" + name.trim() + "'"); } if...

    Mysql查询优化详解（含示例）

    通过分析EXPLAIN的结果，我们可以找出执行计划中的低效部分并进行优化。 #### 二、优化索引 索引是提升查询性能的关键因素之一。合理的索引设计可以显著提高查询速度。下面是一些建议： 1. **确保有合适的索引**...

    经常要用的DB2优化

    - **低效**: `SELECT * FROM EMP WHERE EMPNO &gt; 0 AND DEPTNO IN (SELECT DEPTNO FROM DEPT WHERE LOC = 'MELB')` - **高效**: `SELECT * FROM EMP WHERE EMPNO &gt; 0 AND EXISTS (SELECT 'X' FROM DEPT WHERE DEPT....

    Oracle数据库中分页查询介绍

    由于Web应用的无状态特性，每个请求都是独立的，维持数据库游标以供后续请求是低效的。游标是一种宝贵的资源，应当在每次操作完成后关闭。 Oracle数据库不支持通过行集(rowset)向后移动游标，这意味着一旦用户向前...

    SQL优化 SQL 优化

    **1. 选用适合的Oracle优化器** Oracle数据库支持多种优化器模式： - **基于成本（Cost）**：默认模式，基于统计信息估算查询成本。 - **基于规则（Rule）**：较老的优化策略，适用于特定场景。 - **选择性（Choose...

Magicbox
Global site tag (gtag.js) - Google Analytics