MySQL索引常见问题

专栏持续更新中:MySQL详解

问题1:用联合索引优化using filesort

首先,要给userid加索引(一般过滤条件的字段需要加索引),此时创建的是二级索引树,select *涉及回表。而且还有order by addtime,如果addtime没有建索引的话,explain分析时会出现using filesort,涉及addtime的文件排序!

我们可以添加联合索引(多列索引):userid+addtime

这样的话,在二级索引树上用userid过滤出来的数据中,addtime就已经是有序的了

addtime不建立索引,就有using filesort,数据的外排序。用userid选择出来的数据越多,耗费的排序性能差的越大

addTime有索引,那索引树上的数据就是按照addTime排好序的

问题2:给区分度高的字段加索引

比如我们给sex建立索引,而sex就两种,所以用sex过滤出来的数据可能会占到整张表的一大部分,可能不会用到索引

问题3:select的字段会导致回表

如果不需要那么多的字段,就不要select太多,这会导致回表,影响效率。能直接在二级索引树上取的就直接取,避免回表!

问题4:多个字段有索引,使用哪个索引?

一张表的一次查询只能用到1个索引,数据库引擎会比较用a=1过滤的数据和b=2过滤的数据,哪个索引过滤出来的数据少,就用哪个索引

问题5:内连接之大表和小表

内连接的时候,小表是整表扫描,每一个都要用到,大表相关联的字段没有索引的话,小表的每一个uid在大表中搜索都是整表搜索。如果大表相关联的字段有索引,小表的每一个uid在大表中就是走索引,搜的非常快。

确定大表还是小表:先用where进行数据过滤,谁的数据少谁就是小表

问题6:模糊搜索使用索引

第一个zhang%通配符在后面,可以利用索引进行前缀搜索,可以根据前缀的匹配缩小搜索范围。对于字符串类型来说,索引长度(key_len)不需要很长,只需要能区分每个字符串数据即可,索引过长,导致索引文件变大,创建索引树的时候花费的磁盘I/O也就多了

第二个%zhang%通配符在前面,可以匹配任意的数据,所以只能整张表搜索。如果不扫描完整张表,也不知道到底还有没有含有zhang的数据

问题7:in和not in是否能用到索引?not in优化成range范围搜索

实际上,MySQL做了如下优化:

csharp 复制代码
select age from student where age not in (20);
select age from student where age < 20 or age > 20;  -- 优化成了range范围搜索

not in 可以转化为范围range搜索查询

问题8:索引字段涉及函数以及类型转换,无法用到索引

本来是按照password排序作为索引的,经过函数计算之后就成为了另外的值,所以无法使用索引

索引字段涉及类型强转、mysql聚合函数调用、表达式计算等,不会使用索引

问题9:or不能使用索引?

or 实际上也可以用到索引,MySQL会对or进行优化成union联合查询

优化成union后的两个select应该是都可以使用索引的,究竟用不用,还得看使用索引是否能带来效率的提升

总结

相关推荐
子兮曰4 天前
jev-ultrafast 深度解析:7 秒订机票的浏览器 Agent 是如何炼成的
前端·后端·agent
子兮曰4 天前
Jev 爆发一周:7 秒 Agent 背后的 System One 生态与三场争议
前端·后端·ai编程
爱勇宝4 天前
ZCode 开源 24 小时:一份没有历史的账本,回答不了"有没有偷代码"
前端·后端·chatglm (智谱)
胡写代码4 天前
别再前后端各写一套表单校验了
java·后端
晨米酱4 天前
AGENTS.md:Agent 的上下文策略层
面试·架构·agent
大勇前进4 天前
原生 PHP 还是 Laravel?小项目到底要不要上框架
后端
这个DBA有点耶4 天前
MVCC深入:Read View、版本链与快照读——InnoDB并发控制的内核
数据库·mysql·架构
yuzhi_liu4 天前
我用 LangGraph4j 实现 Multi-Agent Supervisor
后端
alsmile4 天前
Node-RED 之外,国产规则引擎的新方案:基于标准语法,Go 先行实现
后端·开源·go
大白804 天前
PHP 内存溢出排查思路:看懂报错日志,精准定位问题
后端