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

为什么where条件中使用or索引不起作用？where条件中使用or，索引就会失效，会造成全表扫描是误区一，要求使用的所有字段，都必须建立索引。二，数据量太少，制定执行计划时发现全表扫描比索引查找更快。三，确保mysql版本5.0以上，且查询优化器开启了index_merge_union=on, 也就是变量optimizer_switch里存在index_mer

qq_32331073

21299人浏览 · 2018-01-12 15:24:26

qq_32331073 · 2018-01-12 15:24:26 发布

为什么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 the index_merge, index_merge_intersection,index_merge_union, and index_merge_sort_union flags of the optimizer_switch system variable. See Section 8.9.2, “Switchable Optimizations”. By default, all those flags are on.

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

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

该表非常小，全表扫描比索引查找要快。对于少于10行和短行长度的表来说，这很常见。
ON 或 WHERE条件句中不存在可用的索引约束。简单理解为条件句中根本不包含索引列或者包含索引列但是由于条件限制导致索引失效。
将索引列与常量值做比较，并且MYSQL 已经基于索引树计算出这个常量值在表数据中存在的概率很大以至于全表扫描更快。详情见 Section 8.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 算法

一门面向 Data 和 AI 的低代码、云原生的开源编程语言

无需安装部署，在线快速体验 Byzer

更多推荐

byzer plugin install log

Byzer 白泽

函数实现越通用越好？来看看 Byzer-LLM 的 Function Implementation 带来的编程思想大变化...

前言Function Calling 是 OpenAI 首先提出来的一个非常有用的功能，实现了大模型对函数的调用能力。Byzer-LLM 给开源模型也带来了 Function Calling 实现。在这个基础上，我们还拓展了 Respond With Class 功能，允许大模型输出标准的Python对象，进步控制了大模型的输出能力。这两个能力参看：给开源大模型带来Function Callin.