前言

问题是来自于 chinaunix 问题 ”mysql查询后面加 where 1 = 1 影响效率吗?”

mysql 中在 java 代码中我们经常会使用到 ”where 1 = 1 and username = ‘jerry’ ” 之类的条件 

然后 我们这里 来看一下 “where 1 = 1” 的相关处理 

 

 

where 条件在 select_lex, QUP_shared 中的存储

执行 sql 如下 “select *, 2, 2, 2 from tz_test where id = 1;”

sql_lex 中存储的原始查询语句中的查询条件 

因为这里是基于索引的查询, 查询条件放到了 qep_tab->m_qs->m_ref 中 

Qep->tab->m_qs->m_condition 中存储的额外的查询条件为 NULL

50 mysql 的 “where 1 = 1“ 的优化处理_where

 

执行 sql 如下 “select *, 2, 2, 2 from tz_test where field1 = 'field1';”

sql_lex 中存储的原始查询语句中的查询条件 

因为这里是基于索引的查询, 查询条件放到了 qep_tab->m_qs->m_ref 中 

Qep->tab->m_qs->m_condition 中存储的额外的查询条件为 NULL

50 mysql 的 “where 1 = 1“ 的优化处理_where_02

 

执行 sql 如下 “select *, 2, 2, 2 from tz_test where field2 = '1';”

sql_lex 中存储的原始查询语句中的查询条件 

因为这里是不是基于索引的查询, 查询条件放到了 qep_tab->m_qs->m_ref 为 NULL 

Qep->tab->m_qs->m_condition 中存储的的查询条件为 “where field2 = '1'”

50 mysql 的 “where 1 = 1“ 的优化处理_optimize_03

 

执行 sql 如下 “select *, 2, 2, 2 from tz_test where rand() > 0.4;”

sql_lex 中存储的原始查询语句中的查询条件 

因为这里是不是基于索引的查询, 查询条件放到了 qep_tab->m_qs->m_ref 为 NULL 

Qep->tab->m_qs->m_condition 中存储的的查询条件为 “where rand() > 0.4”

50 mysql 的 “where 1 = 1“ 的优化处理_mysql_04

 

执行 sql 如下 “select *, 2, 2, 2 from tz_test where '1' = '1';”

sql_lex 中存储的原始查询语句中的查询条件 

因为这里是不是基于索引的查询, 查询条件放到了 qep_tab->m_qs->m_ref 为 NULL 

Qep->tab->m_qs->m_condition 中存储的的查询条件为 NULL, 因为在之前的 optimize的过程中查询条件被优化了 

50 mysql 的 “where 1 = 1“ 的优化处理_sql_05

 

 

select_lex -> JOIN -> QEP_shared  

select_lex 传递 where_cond 到 JOIN

50 mysql 的 “where 1 = 1“ 的优化处理_sql_06

 

JOIN 传递 where_cond 到 QEP_shared

50 mysql 的 “where 1 = 1“ 的优化处理_where_07

 

 

JOIN optimize 的过程中 where_cond 的清理 

条件的清理是在这里, 这里判断出来的 ”where 1 = 1” 恒为 true 

然后 这里的 ”*returncond = NULL” 就是清理掉条件 

50 mysql 的 “where 1 = 1“ 的优化处理_mysql_08

 

”*returncond = NULL” 执行了之后, JOIN->where_cond 更新为了 NULL

然后 导致 向后面的 table_ref, m_condition 传递存在问题 

50 mysql 的 “where 1 = 1“ 的优化处理_mysql_09