您当前的位置:首页 > 计算机 > 软件应用 > 数据库 > MySQL

为什么where条件中使用or索引不起作用?

时间:05-13来源:作者:点击数:

为什么where条件中使用or索引不起作用?where条件中使用or,索引就会失效,会造成全表扫描 是误区

一,要求使用的所有字段,都必须建立索引。

二,数据量太少,制定执行计划时发现全表扫描比索引查找更快。

三,确保mysql版本5.0以上,且查询优化器开启了index_merge_union=on, 也就是变量optimizer_switch里存在index_merge_union且为on

Note:Use of Index Merge is subject to the value of theindex_merge,index_merge_intersection,index_merge_union, andindex_merge_sort_unionflags of theoptimizer_switchsystem variable. SeeSection8.9.2, “Switchable Optimizations”. By default, all those flags areon.

合并索引是否使用取决于优化器开关的系统参数值,默认情况下这些参数值都为on,如果需要重新设置,请参照Section8.9.2, “Switchable Optimizations”

Note :EXPALIN看到type列的值为ALL,意味着MYSQL使用全表扫描解析查询。MYSQL使用全表扫描去解析查询通常有如下几种条件:

  • 该表非常小,全表扫描比索引查找要快。对于少于10行和短行长度的表来说,这很常见。
  • ONWHERE条件句中不存在可用的索引约束。简单理解为条件句中根本不包含索引列或者包含索引列但是由于条件限制导致索引失效。
  • 将索引列与常量值做比较,并且MYSQL已经基于索引树计算出这个常量值在表数据中存在的概率很大以至于全表扫描更快 。详情见Section8.2.1.1, “WHERE Clause Optimization”
  • 类似于上一情况,使用唯一性较低的列作为索引列,这种情况下,MYSQL假定全表扫描比索引查找更快。

例子:

找一含几千万数据的表, explain了一下or查询

# id是主键, user_id是普通索引
explain SELECT * from t WHERE id = 100000 or user_id = 'c7b6752c37b111e6a7d705b57e583e2e';
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t index_merge PRIMARY,t_userid PRIMARY,t_userid 4,123   2 Using union(PRIMARY,t_userid);

Type :index_merge 表明使用了合并索引

Extra :Using union(PRIMARY,t_userid); 表明合并为index_merge 索引使用了union算法

方便获取更多学习、工作、生活信息请关注本站微信公众号城东书院 微信服务号城东书院 微信订阅号
推荐内容
相关内容
栏目更新
栏目热门