sqllike判断为空_日拱一卒，SQL语法优化方法及实例详解

如果经常执行如上查询&＃xff0c;那么建立三个单独索引不如建立一个复合索引&＃xff0c;因为三个单独索引通常数据库每次执行只能使用其中一个&＃xff0c;虽然这样比不使用索引而进行全表扫描提高了很多效率&＃xff0c;但使用复合索引因为索引本身就对应到三个字段上的&＃xff0c;效率会有更大提升。

那么为什么数据库只支持一条查询语句只使用一个索引&＃xff1f;简单的讲是因为N个独立索引同时在一条语句使用的效果比只使用一个索引还要慢&＃xff0c;开销太大。

在使用索引字段作为条件时&＃xff0c;如果该索引是复合索引&＃xff0c;那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引&＃xff0c;否则该索引将不会被使用&＃xff0c;并且应尽可能的让字段顺序与索引顺序相一致。

同时&＃xff0c;复合索引的也是有生效原则的&＃xff0c;其原则是从前往后依次使用则生效&＃xff0c;如果中间某个索引没有使用&＃xff0c;那么“断点”前面的索引生效&＃xff0c;断点后面的索引不生效&＃xff0c;造成“断点”的原因一般有&＃xff1a;

• 前边的任意一个索引没有参与查询&＃xff0c;后面的不生效。
• 前边的任意一个索引失效&＃xff0c;当前索引及后面的不生效。
• 前边的任意一个索引字段参与的是范围查询&＃xff0c;后面的不生效。

引发索引失效&＃xff0c;导致全表扫描的原因有&＃xff1a;

• 索引列进行计算、函数、类型转换等操作。
• 索引列使用不等于&＃xff0c;如!&＃61; 或<>。
• 索引列使用 IS NULL &＃xff0c;IS NOT NULL。
• 模糊查询LIKE 以通配符开头如&＃xff0c;%ab。
• 索引列使用使用 OR 来连接条件。
• 索引列使用IN 和 NOT IN 。
• 类型错误&＃xff0c;如字段NUM类型为varchar&＃xff0c;WHERE条件用number&＃xff0c;NUM &＃61; 1。
• WHERE子句和ORDER BY使用相同的索引&＃xff0c;并且ORDER BY的顺序和索引顺序相同&＃xff0c;并且ORDER BY的字段都是升序或者降序&＃xff0c;否则不会使用索引。
• 复合索引不符合最佳左前缀原则或存在断点。
• 如果MYSQL评估使用索引比全表扫描更慢&＃xff0c;则不使用索引。

例如我们建立了一个这样复合索引key index (col1,col2,col3)&＃xff0c;那么其实相当于创建了(col1)&＃xff0c;(col1,col2)&＃xff0c;(col1,col2,col3)三个索引&＃xff0c;即最佳左前缀特性。

应尽量避免在 WHERE 子句中使用 !&＃61; 或 <> 操作符&＃xff0c;否则将导致引擎放弃使用索引而进行全表扫描。MySQL只有对以下操作符才使用索引&＃xff1a;&＃xff0c;>&＃61;&＃xff0c;BETWEEN&＃xff0c;IN&＃xff0c;以及某些方式的LIKE(&＃39;a%&＃39;)&＃xff0c;如下。

WHERE 子句中使用 LIKE进行模糊查询时&＃xff0c;在关键词前加通配符或者前后都加通配号都无法使用索引&＃xff0c;从而引发全表扫描。解决LIKE &＃39;%abc%&＃39; 时索引不被使用的方法就是添加覆盖索引(只访问索引的查询&＃xff0c;索引和查询列一致&＃xff0c;只需扫描索引而无须回表)&＃xff0c;如下。

应尽量避免在 WHERE 子句中对字段进行 NULL 值判断&＃xff0c;否则将导致引擎放弃使用索引而进行全表扫描&＃xff0c;创建表时NULL是默认值&＃xff0c;但大多数时候应该使用NOT NULL&＃xff0c;或者使用一个默认值&＃xff0c;如 0 作为默认值。

例如&＃xff0c;性别&＃xff0c;使用1表示男&＃xff0c;2表示女&＃xff0c;0表示未知或者是用户没有选择&＃xff0c;默认值设置为 0&＃xff0c;因为大部分编程语言的数字类型的默认值0&＃xff0c;如下。

空值和NULL是有区别的&＃xff0c;以一个杯子为例&＃xff1a;

• 空值代表杯子是真空的。
• NULL代表杯子中装满了空气。

如果字段允许为空&＃xff0c;可能会有以下问题&＃xff1a;

• 查询条件就必须处理为空的情况&＃xff0c;否则会出现一些很奇怪的问题&＃xff0c;比如NOT IN、!&＃61; 等负向条件查询在有 NULL 值的情况下返回始终为空结果&＃xff0c;查询易出错。
• 在部分数据库中会导致索引失效。
• 可空列需要更多的存储空间&＃xff0c;导致空间变大&＃xff0c;增加数据库系统查询分析复杂度。
• 在程序中可能需要每次都判断是否为空&＃xff0c;增加程序复杂复杂度。

但凡事没有绝对的&＃xff0c;使用默认值的思路可以解决很大一部分可为空的问题&＃xff0c;但不是所有都需这样做&＃xff0c;具体还是要根据具体业务进行分析。

应尽量避免在 WHERE 子句中使用 OR 来连接条件&＃xff0c;否则将导致引擎放弃使用索引而进行全表扫描。使用 OR 的字句可以分解成多个查询&＃xff0c;并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关&＃xff0c;如果查询需要用到联合索引&＃xff0c;用UNION ALL执行的效率更高&＃xff0c;如下。

应尽量避免在 WHERE 子句中使用 IN 和 NOT IN &＃xff0c;否则将导致全表扫描&＃xff0c;对于连续的数值&＃xff0c;能用 BETWEEN AND 尽量避免使用 IN。一般&＃xff0c;用 EXISTS 代替 IN 。若需要使用 IN&＃xff0c;在 IN 后面值的列表中&＃xff0c;按照值的分布数量降序排列&＃xff0c;减少判断的次数。

使用BETWEEN AND 替换 IN &＃xff0c;如下。

使用EXISTS 替代IN&＃xff0c;用NOT EXISTS 替代 NOT IN&＃xff0c;无论在哪种情况下&＃xff0c; NOT IN效率都是最低的&＃xff0c;如下。

使用LEFT JOIN 替换 IN&＃xff0c;如下。

如上&＃xff0c;我们使用了如下方式优化了IN 和 NOT IN:

• 使用between 替换 in ( 如果 in 的条件是连续的)
• 使用exists替代in、用not exists替代 not in
• 使用left join 替换 in

应尽量避免在 WHERE 子句中对 “&＃61;” 左边的字段进行函数、算术运算及其他表达式运算&＃xff0c;可以将表达式运算移至“&＃61;”右边&＃xff0c;否则将导致引擎放弃使用索引而进行全表扫描&＃xff0c;如下。

如果在 WHERE 子句中使用参数&＃xff0c;也会导致全表扫描。因为SQL只有在运行时才会解析局部变量&＃xff0c;但优化程序不能将访问计划的选择推迟到运行时。它必须在编译时进行选择。然而&＃xff0c;如果在编译时建立访问计划&＃xff0c;变量的值还是未知的&＃xff0c;因而无法作为索引选择的输入项&＃xff0c;可以改为强制查询使用索引&＃xff0c;如下。

在分页查询偏移量特别大时&＃xff0c;LIMIT 效率会相当低&＃xff0c;如下。

存在如下表&＃xff0c;n_id是主键&＃xff0c;id_card是人员编码&＃xff0c;数字类型&＃xff0c;表中id_card有重复&＃xff0c;已经建了id_card索引&＃xff0c;如下。

EXISTS语句用来判断括号内的表达式是否存在返回值&＃xff0c;如果存在就返回真&＃xff0c;如果不存在就返回假&＃xff0c;同时它只要括号中的表达式有一个值存在&＃xff0c;就立刻返回真&＃xff0c;而不需要遍历表中所有的数据&＃xff0c;正是因此 EXISTS 使查询效率更高&＃xff0c;如下。