新泰网站建设方案,wordpress超cpu,下载ppt模板免费的网站,罗伯特清崎说的网络营销是什么一、索引概述
1.1、概述 索引#xff08;index#xff09;是帮助MySQL高效获取数据的数据结构(有序)。在数据之外#xff0c;数据库系统还维护着满足特定查找算法的数据结构#xff0c;这些数据结构以某种方式引用#xff08;指向#xff09;数据#xff0c; 这样就可以…一、索引概述
1.1、概述 索引index是帮助MySQL高效获取数据的数据结构(有序)。在数据之外数据库系统还维护着满足特定查找算法的数据结构这些数据结构以某种方式引用指向数据 这样就可以在这些数据结构上实现高级查找算法这种数据结构就是索引。1.2、演示
表结构及其数据如下假如我们要执行的SQL语句为 select * from user where age 45;
1.2.1、无索引情况 在无索引情况下就需要从第一行开始扫描一直扫描到最后一行我们称之为 全表扫描性能很低。
1.2.2、有索引情况
如果我们针对于这张表建立了索引假设索引结构就是二叉树那么也就意味着会对age这个字段建立一个二叉树的索引结构。此时我们在进行查询时只需要扫描三次就可以找到数据了极大的提高的查询的效率。 备注这里我们只是假设索引的结构是二叉树介绍一下索引的大概原理只是一个示意图并不是索引的真实结构索引的真实结构后面会详细介绍。
1.3、特点 二、索引结构
2.1、概述
MySQL的索引是在存储引擎层实现的不同的存储引擎有不同的索引结构主要包含以下几种2.2、不同存储引擎对索引结构的支持 注意事项我们平常所说的索引如果没有特别指明都是指B树结构的索引。
2.3、二叉树
假如说MySQL的索引结构采用二叉树的数据结构比较理想的结构如下如果主键是顺序插入的则会形成一个单向链表结构如下 所以如果选择二叉树作为索引结构会存在以下缺点 顺序插入时会形成一个链表查询性能大大降低。 大数据量情况下层级较深检索速度慢。 此时大家可能会想到我们可以选择红黑树红黑树是一颗自平衡二叉树那这样即使是顺序插入数据最终形成的数据结构也是一颗平衡的二叉树,结构如下: 但是即使如此由于红黑树也是一颗二叉树所以也会存在一个缺点 大数据量情况下层级较深检索速度慢。 所以在MySQL的索引结构中并没有选择二叉树或者红黑树而选择的是BTree那么什么是BTree呢在详解BTree之前先来介绍一个B-Tree。 2.4、B-Tree B-TreeB树是一种多叉路衡查找树相对于二叉树B树每个节点可以有多个分支即多叉。以一颗最大度数max-degree为5(5阶)的b-tree为例那这个B树每个节点最多存储4个key5个指针 可视化网站
https://www.cs.usfca.edu/~galles/visualization/BTree.html# 测试数据
100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88
120 268 250
特点
5阶的B树每一个节点最多存储4个key对应5个指针。 一旦节点存储的key数量到达5就会裂变中间元素向上分裂。在B树中非叶子节点和叶子节点都会存放数据。
2.5、BTree
BTree是B-Tree的变种我们以一颗最大度数max-degree为44阶的btree为例来看一下其结构示意图 绿色框框起来的部分是索引部分仅仅起到索引数据的作用不存储数据。 红色框框起来的部分是数据存储部分在其叶子节点中要存储具体的数据。
可视化网站https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html# 测试数据
100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88
120 268 2502.6、BTree和B-Tree的区别 所有的数据都会出现在叶子节点;叶子节点形成一个单向链表;非叶子节点仅仅起到索引数据作用具体的数据都是在叶子节点存放的;上述我们所看到的结构是标准的BTree的数据结构接下来我们再来看看MySQL中优化之后的 BTree。MySQL索引数据结构对经典的BTree进行了优化。在原BTree的基础上增加一个指向相邻叶子节点的链表指针就形成了带有顺序指针的BTree提高区间访问的性能利于排序。2.7、Hash
MySQL中除了支持BTree索引还支持一种索引类型Hash索引。结构哈希索引就是采用一定的hash算法将键值换算成新的hash值映射到对应的槽位上然后存储在hash表中。如果两个(或多个)键值映射到一个相同的槽位上他们就产生了hash冲突也称为hash碰撞可以通过链表来解决。 特点 Hash索引只能用于对等比较(in)不支持范围查询between ... 无法利用索引完成排序操作查询效率高通常(不存在hash冲突的情况)只需要一次检索就可以了效率通常要高于Btree索引存储引擎支持 在MySQL中支持hash索引的是Memory存储引擎。 而InnoDB中具有自适应hash功能hash索引是InnoDB存储引擎根据BTree索引在指定条件下自动构建的。
2.8、思考题为什么InnoDB的存储引擎选择使用BTree索引结构 相对于二叉树层级更少搜索效率高 对于B-Tree无论是叶子节点还是非叶子节点都会保存数据这样导致一页中存储的键值减少指针跟着减少要同样保存大量数据只能增加树的高度导致性能降低 相对Hash索引BTree支持范围匹配及排序操作
三、索引分类
3.1、索引分类
在MySQL数据库将索引的具体类型主要分为以下几类主键索引、唯一索引、常规索引、全文索引。 3.2、聚集索引 二级索引
在InnoDB存储引擎中根据索引的存储形式可以分为以下两种3.2.1、聚集索引选取规则
如果存在主键主键索引就是聚集索引如果不存在主键将使用第一个唯一UNIQUE索引作为聚集索引如果表没有主键或没有合适的唯一索引则InnoDB会自动生成一个rowid作为隐藏的聚集索引
3.2.2、聚集索引和二级索引的具体结构 结论
聚集索引的叶子节点下挂的是这一行的数据; 二级索引的叶子节点下挂的是该字段值对应的主键值; 3.2.3、具体SQL的执行过程 具体过程
由于是根据name字段进行查询所以先根据nameArm到name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到Arm对应的主键值10 由于查询返回的数据是*所以此时还需要根据主键值10到聚集索引中查找10对应的记录最终找到10对应的行row 最终拿到这一行的数据直接返回即可
3.2.4、回表查询
类似于3.2.3中这种先到二级索引中查找数据找到主键值然后再到聚集索引中根据主键值获取数据的方式就称之为回表查询。
四、索引语法
4.1、创建索引
CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name,... ) ;
4.2、查看索引
SHOW INDEX FROM table_name ;
4.3、删除索引
DROP INDEX index_name ON table_name ;
4.4、案例演示
4.4.1、初始表tb_user
use itheima;
drop table if exists tb_user;
create table tb_user(id int primary key auto_increment comment 主键,name varchar(50) not null comment 用户名,phone varchar(11) not null comment 手机号,email varchar(100) comment 邮箱,profession varchar(11) comment 专业,age tinyint unsigned comment 年龄,gender char(1) comment 性别 , 1: 男, 2: 女,status char(1) comment 状态,createtime datetime comment 创建时间
) comment 系统用户表;INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (吕布, 17799990000, lvbu666163.com, 软件工程, 23, 1,6, 2001-02-02 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (曹操, 17799990001, caocao666qq.com, 通讯工程, 33,1, 0, 2001-03-05 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (赵云, 17799990002, 17799990139.com, 英语, 34, 1,2, 2002-03-02 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (孙悟空, 17799990003, 17799990sina.com, 工程造价, 54,1, 0, 2001-07-02 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (花木兰, 17799990004, 19980729sina.com, 软件工程, 23,2, 1, 2001-04-22 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (大乔, 17799990005, daqiao666sina.com, 舞蹈, 22, 2,0, 2001-02-07 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (露娜, 17799990006, luna_lovesina.com, 应用数学, 24,2, 0, 2001-02-08 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (程咬金, 17799990007, chengyaojin163.com, 化工, 38,1, 5, 2001-05-23 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (项羽, 17799990008, xiaoyu666qq.com, 金属材料, 43,1, 0, 2001-09-18 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (白起, 17799990009, baiqi666sina.com, 机械工程及其自动化, 27, 1, 2, 2001-08-16 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (韩信, 17799990010, hanxin520163.com, 无机非金属材料工程, 27, 1, 0, 2001-06-12 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (荆轲, 17799990011, jingke123163.com, 会计, 29, 1,0, 2001-05-11 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (兰陵王, 17799990012, lanlinwang666126.com, 工程造价,44, 1, 1, 2001-04-09 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (狂铁, 17799990013, kuangtiesina.com, 应用数学, 43,1, 2, 2001-04-10 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (貂蝉, 17799990014, 84958948374qq.com, 软件工程, 40,2, 3, 2001-02-12 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (妲己, 17799990015, 2783238293qq.com, 软件工程, 31,2, 0, 2001-01-30 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (芈月, 17799990016, xiaomin2001sina.com, 工业经济, 35,2, 0, 2000-05-03 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (嬴政, 17799990017, 8839434342qq.com, 化工, 38, 1,1, 2001-08-08 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (狄仁杰, 17799990018, jujiamlm8166163.com, 国际贸易,30, 1, 0, 2007-03-12 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (安琪拉, 17799990019, jdodm1h126.com, 城市规划, 51,2, 0, 2001-08-15 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (典韦, 17799990020, ycaunanjian163.com, 城市规划, 52,1, 2, 2000-04-12 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (廉颇, 17799990021, lianpo321126.com, 土木工程, 19,1, 3, 2002-07-18 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (后羿, 17799990022, altycj2000139.com, 城市园林, 20,1, 0, 2002-03-10 00:00:00);
INSERT INTO tb_user (name, phone, email, profession, age, gender, status,createtime) VALUES (姜子牙, 17799990023, 37483844qq.com, 工程造价, 29,1, 4, 2003-05-26 00:00:00); 4.4.2、案例一name字段为姓名字段该字段的值可能会重复为该字段创建索引
CREATE INDEX idx_user_name ON tb_user(name); 4.4.2、案例二phone手机号字段的值是非空且唯一的为该字段创建唯一索引
CREATE UNIQUE INDEX idx_user_phone ON tb_user(phone); 4.4.3、案例三为profession、age、status创建联合索引
CREATE INDEX idx_user_pro_age_sta ON tb_user(profession,age,status); 4.4.4、案例四为email建立合适的索引来提升查询效率
CREATE INDEX idx_email ON tb_user(email); 4.4.5、案例五、查看tb_user表的所有索引
show index from tb_user; 五、SQL性能分析
5.1、SQL执行频率
# 查看数据库的INSERT、UPDATE、DELETE、SELECT执行频率
-- session 是查看当前会话 ;
-- global 是查询全局数据 ;SHOW GLOBAL STATUS LIKE Com_______;Com_insert: 插入次数
Com_update: 更新次数
Com_delete: 删除次数
Com_select: 查询次数通过上述指令我们可以查看到当前数据库到底是以查询为主还是以增删改为主从而为数据 库优化提供参考依据。 如果是以增删改为主我们可以考虑不对其进行索引的优化。 如果是以 查询为主那么就要考虑对数据库的索引进行优化了。5.2、百万级别数据导入
5.2.0、readme
由于1000w的数据量较大 , 如果直接加载1000w , 会非常耗费CPU及内存 ;已经拆分为5个部分 , 每一个部分为200w数据 , load 5次即可 ;
5.2.1、建表语句
drop table if exists tb_sku;
CREATE TABLE tb_sku (id int(11) NOT NULL AUTO_INCREMENT COMMENT 商品id,sn varchar(100) NOT NULL COMMENT 商品条码,name varchar(200) NOT NULL COMMENT SKU名称,price int(20) NOT NULL COMMENT 价格分,num int(10) NOT NULL COMMENT 库存数量,alert_num int(11) DEFAULT NULL COMMENT 库存预警数量,image varchar(200) DEFAULT NULL COMMENT 商品图片,images varchar(2000) DEFAULT NULL COMMENT 商品图片列表,weight int(11) DEFAULT NULL COMMENT 重量克,create_time datetime DEFAULT NULL COMMENT 创建时间,update_time datetime DEFAULT NULL COMMENT 更新时间,category_name varchar(200) DEFAULT NULL COMMENT 类目名称,brand_name varchar(100) DEFAULT NULL COMMENT 品牌名称,spec varchar(200) DEFAULT NULL COMMENT 规格,sale_num int(11) DEFAULT 0 COMMENT 销量,comment_num int(11) DEFAULT 0 COMMENT 评论数,status char(1) DEFAULT 1 COMMENT 商品状态 1-正常2-下架3-删除,PRIMARY KEY (id) USING BTREE
) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;
5.2.2、查询 local_infile 的默认配置
SHOW GLOBAL VARIABLES LIKE local_infile; 5.2.3、开启 local_infile 配置
SET GLOBAL local_infile true; 5.2.4、退出并重新登录
mysql --local-infile1 -uroot -p123456 5.2.5、再次查询 local_infile 配置
SHOW GLOBAL VARIABLES LIKE local_infile; 5.2.6、执行导入指令
load data local infile D:/temp/tb_sku1.sql into table tb_sku fields terminated by , lines terminated by \n;
load data local infile D:/temp/tb_sku2.sql into table tb_sku fields terminated by , lines terminated by \n;
load data local infile D:/temp/tb_sku3.sql into table tb_sku fields terminated by , lines terminated by \n;
load data local infile D:/temp/tb_sku4.sql into table tb_sku fields terminated by , lines terminated by \n;
load data local infile D:/temp/tb_sku5.sql into table tb_sku fields terminated by , lines terminated by \n; 5.2.7、sql脚本
链接https://pan.baidu.com/s/1y7t6Ztq5Z6pz8q0hhN9jPA?pwdyyds
提取码yyds 5.3、慢查询日志 慢查询日志记录了所有执行时间超过指定参数long_query_time单位秒默认10秒的所有 SQL语句的日志。MySQL的慢查询日志默认没有开启我们可以查看一下系统变量 slow_query_log对应的sqlshow variables like %slow_query_log%。5.2.1、Windows开启慢查询日志
#1、 查询datadir的位置show variables like datadir;#2、在datadir找到my.ini文件,修改如下内容slow-query-log1 # 开启MySQL慢日志查询开关long_query_time2 # 设置慢日志的时间为2秒SQL语句执行时间超过2秒就会视为慢查询记录慢查询日志#3、重启mysql服务5.2.2、Linux开启慢查询日志
# 1、修改/etc/my.cnf# 2、修改内容如下slow_query_log1 # 开启MySQL慢日志查询开关long_query_time2 # 设置慢日志的时间为2秒SQL语句执行时间超过2秒就会视为慢查询记录慢查询日志# 3、配置完毕之后通过以下指令重新启动MySQL服务器进行测试查看慢日志文件中记录的信息
/var/lib/mysql/${hostname}-slow.logsystemctl restart mysqld
5.3.4、测试
执行如下sql观察结果 select * from tb_user; -- 这条SQL执行效率比较高, 执行耗时 0.00sec
select count(*) from tb_sku; -- 由于tb_sku表中, 预先存入了1000w的记录, count一次,耗时
8.32sec 检查慢查询日志 最终我们发现在慢查询日志中只会记录执行时间超多我们预设时间2s的sql执行较快的sql是不会记录的。 Windows中的日志C:\ProgramData\MySQL\MySQL Server 8.0\Data\${name}-slow.log Linux中的日志位置/var/lib/mysql/${hostname}-slow.log 执行的指令tail -f centos71-slow.log 通过慢查询日志就可以定位出执行效率比较低的SQL从而有针对性的进行优化
5.4、profile详情
5.4.1、概述
show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。
5.4.2、查看当前MySQL是否支持profile操作
select have_profiling; 5.4.2、查看profile是否处于开启 状态 select profiling; 5.4.3、开启profile
SET [global|session] profiling 1; 5.4.4、profile已开启下面执行的sql都会被记录
select * from tb_user;
select * from tb_user where id 1;
select * from tb_user where name 白起;
select count(*) from tb_sku;
5.4.5、查看指令的执行耗时 查看每一条SQL的耗时基本情况 show profiles; 查看指定query_id的SQL语句各个阶段的耗时情况 # 语法
show profile for query query_id;# 案例
show profile for query 4; 查看指定query_id的SQL语句CPU的使用情况 # 语法
show profile cpu for query query_id;# 案例
show profile cpu for query 4;
5.5、explain
EXPLAIN或者DESC命令用于获取MySQL如何执行SELECT语句的信息包括在SELECT语句执行过程中表如何连接和连接的顺序。5.5.1、语法
-- 直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ; 5.5.2、explain各个字段的含义 六、索引使用
6.1、验证索引效率
6.1.1、未使用索引执行count(*观察执行结果 select count(*) from tb_sku; 6.1.2、根据id查询id有主键观察执行结果 select * from tb_sku where id 1\G; 结果可以看到即使有1000w的数据,根据id进行数据查询,性能依然很快因为主键id是有索引的。 6.1.3、根据 sn 字段进行查询sn字段无索引 SELECT * FROM tb_sku WHERE sn 100000003145001\G; 结果 到根据sn字段进行查询查询返回了一条数据结果耗时 20.78sec就是因为sn没有索引而造成查询效率很低 6.1.4、根据 sn 字段进行查询sn字段有索引
# 在sn字段建立索引
create index idx_sku_sn on tb_sku(sn) ;SELECT * FROM tb_sku WHERE sn 100000003145001\G; 6.2、最左前缀法则 如果索引了多列联合索引要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始并且不跳过索引中的列。如果跳跃某一列索引将会部分失效(后面的字段索引失效)。6.2.1、当前tb_user表中的所有索引
show index from tb_user; 在 tb_user 表中有一个联合索引这个联合索引涉及到三个字段顺序分别为profession agestatus。对于最左前缀法则指的是查询时最左边的列也就是profession必须存在否则索引全部失效。而且中间不能跳过某一列否则该列后面的字段索引将失效。6.2.2、案例1满足最左前缀法则
explain select * from tb_user where profession 软件工程 and age 31 and status 0;
explain select * from tb_user where profession 软件工程 and age 31;
explain select * from tb_user where profession 软件工程;以上的这三组测试中我们发现只要联合索引最左边的字段 profession存在索引就会生效只不过索引的长度不同。 而且由以上三组测试我们也可以推测出profession字段索引长度为47、age字段索引长度为2、status字段索引长度为5。
6.2.3、案例2不满足最左前缀法则
explain select * from tb_user where age 31 and status 0;
explain select * from tb_user where status 0; 通过上面的这两组测试可以看到索引并未生效原因是因为不满足最左前缀法则联合索引最左边的列profession不存在。
6.2.4、案例3满足最左前缀法则跳过中间字段
explain select * from tb_user where profession 软件工程 and status 0; 上述的SQL查询时存在profession字段最左边的列是存在的索引满足最左前缀法则的基本条 件。但是查询时跳过了age这个列所以后面的列索引是不会使用的也就是索引部分生效所以索引的长度就是47。6.2.5、思考题 当执行SQL语句: explain select * from tb_user where age 31 and status 0 and profession 软件工程; 时是否满足最左前缀法则走不走 上述的联合索引索引长度可以看到是完全满足最左前缀法则的索引长度54联合索引是生效的。
注意 最左前缀法则中指的最左边的列是指在查询时联合索引的最左边的字段(即是第一个字段)必须存在与我们编写SQL时条件编写的先后顺序无关。 6.3、范围查询
6.3.1、,
联合索引中出现范围查询(,)范围查询右侧的列索引将失效。 explain select * from tb_user where profession 软件工程 and age 30 and status 0; 当范围查询使用 或 时走联合索引了但是索引的长度为49就说明范围查询右边的status字段是没有走索引的。 6.3.2、, explain select * from tb_user where profession 软件工程 and age 30 and status 0; 当范围查询使用 或 时走联合索引了但是索引的长度为54就说明所有的字段都是走索引 的。 6.3.3、结论
所以在业务允许的情况下尽可能的使用类似于 或 这类的范围查询而避免使用 或 6.4、索引失效情况
6.4.1、索引列运算
不要在索引列上进行运算操作否则索引将失效。当前tb_user表中的索引情况。 show index from tb_user; 根据phone字段进行等值查询索引生效explain select * from tb_user where phone 17799990015; 根据phone字段进行函数运算索引失效 explain select * from tb_user where substring(phone,10,2) 15; 6.4.2、字符串不加引号
字符串类型字段使用时不加引号索引将失效。当前tb_user的表结构explain select * from tb_user where profession 软件工程 and age 31 and status 0;
explain select * from tb_user where profession 软件工程 and age 31 and status 0;
explain select * from tb_user where phone 17799990015;
explain select * from tb_user where phone 17799990015; 经过上面两组示例我们会明显的发现如果字符串不加单引号对于查询结果没什么影响但是数据库存在隐式类型转换索引将失效。 6.4.3、模糊查询
如果仅仅是尾部模糊匹配索引不会失效。如果是头部模糊匹配索引失效。explain select * from tb_user where profession like 软件%;
explain select * from tb_user where profession like %工程;
explain select * from tb_user where profession like %工%; 经过上述的测试我们发现在like模糊查询中在关键字后面加%索引可以生效。而如果在关键字前面加了%索引将会失效。 6.4.4、or连接条件 用or分割开的条件 如果or前的条件中的列有索引而后面的列中没有索引那么涉及的索引都不会被用到。 当前tb_user表中的索引情况 explain select * from tb_user where id 10 or age 23;
explain select * from tb_user where phone 17799990017 or age 23;
explain select * from tb_user where id 10 or phone 17799990017; 针对age字段建立索引后再次执行上述SQL create index idx_user_age on tb_user(age);show index from tb_user; 总结当or连接的条件左右两侧字段都有索引时索引才会生效。 6.4.5、数据分布影响
如果MySQL评估使用索引比全表更慢则不使用索引。explain select * from tb_user where phone 17799990005;
explain select * from tb_user where phone 17799990015;经过测试我们发现相同的SQL语句只是传入的字段值不同最终的执行计划也完全不一样这是为 什么呢 就是因为MySQL在查询时会评估使用索引的效率与走全表扫描的效率如果走全表扫描更快则放弃索引走全表扫描。 因为索引是用来索引少量数据的如果通过索引查询返回大批量的数据则还不如走全表扫描来的快此时索引就会失效。 验证 is null 与 is not null 操作是否走索引 explain select * from tb_user where profession is null;
explain select * from tb_user where profession is not null;将tb_user表的profession字段全部置为null再次执行上述SQL观察结果 update tb_user set profession null; 最终我们看到一模一样的SQL语句先后执行了两次结果查询计划是不一样的为什么会出现这种现象呢这是和数据库的数据分布有关系。查询时MySQL会评估走索引快还是全表扫描快如果全表扫描更快则放弃索引走全表扫描。 因此is null 、is not null是否走索引得具体情况具体分析并不是固定的。 6.5、SQL提示
6.5.1、当前tb_user表的数据情况及索引情况 6.5.2、删除索引 idx_email 和 idx_user_age
drop index idx_user_age on tb_user;
drop index idx_email on tb_user; 6.5.3、创建profession的单列索引执行查询观察结果
create index idx_user_pro on tb_user(profession);
show index from tb_user;
explain select * from tb_user where profession 软件工程; 测试结果我们可以看到possible_keys中 idx_user_pro_age_sta,idx_user_pro 这两个索引都可能用到最终MySQL选择了idx_user_pro_age_sta索引。这是MySQL自动选择的结果。那么我们能不能在查询的时候自己来指定使用哪个索引呢 答案是肯定的此时就可以借助于MySQL的SQL提示来完成。 接下来介绍一下SQL提示。SQL提示是优化数据库的一个重要手段简单来说就是在SQL语句中加入一些人为的提示来达到优化操作的目的。
6.5.4、use index
建议MySQL使用哪一个索引完成此次查询仅仅是建议mysql内部还会再次进行评估explain select * from tb_user use index(idx_user_pro) where profession 软件工程; 6.5.5、ignore index 忽略指定的索引。 explain select * from tb_user ignore index(idx_user_pro) where profession 软件工程; 6.5.6、force index 强制使用索引。 explain select * from tb_user force index(idx_user_pro) where profession 软件工程; 6.6、覆盖索引
6.6.1、概述
覆盖索引是指查询使用了索引并且需要返回的列在该索引中已经全部能够找到。explain select id, profession from tb_user where profession 软件工程 and age 31 and status 0 ;explain select id,profession,age, status from tb_user where profession 软件工程 and age 31 and status 0 ;explain select id,profession,age, status, name from tb_user where profession 软件工程 and age 31 and status 0 ;explain select * from tb_user where profession 软件工程 and age 31 and status 0; 从上述的执行计划我们可以看到这四条SQL语句的执行计划前面所有的指标都是一样的看不出来差异。但是此时我们主要关注的是后面的Extra前面两天SQL的结果为 Using where; Using Index ; 而后面两条SQL的结果为: Using index condition。 因为在tb_user表中有一个联合索引 idx_user_pro_age_sta该索引关联了三个字段 profession、age、status而这个索引也是一个二级索引所以叶子节点下面挂的是这一行的主键id。 所以当我们查询返回的数据在 id、profession、age、status 之中则直接走二级索引直接返回数据了。 如果超出这个范围就需要拿到主键id再去扫描聚集索引再获取额外的数据了这个过程就是回表。 而我们如果一直使用select * 查询返回所有字段值很容易就会造成回表查询除非是根据主键查询此时只会扫描聚集索引。 6.6.2、覆盖索引 回表查询 A、表结构及其示意图 id是主键是一个聚集索引。 name字段建立了普通索引是一个二级索引辅助索引 B、执行SQL : select * from tb_user where id 2; 根据id查询直接走聚集索引查询一次索引扫描直接返回数据性能高。 C、执行SQLselet id,name from tb_user where name Arm;虽然是根据name字段查询查询二级索引但是由于查询返回的字段为 idname在name的二级索引中这两个值都是可以直接获取到的因为覆盖索引所以不需要回表查询性能高。D、执行SQLselet id,name,gender from tb_user where name Arm; 由于在name的二级索引中不包含gender所以需要两次索引扫描也就是需要回表查询性能相对较差一点。 6.6.3、思考 一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案: select id,username,password from tb_user where username itcast;6.7、前缀索引
6.7.1、概述 当字段类型为字符串varchartextlongtext等时有时候需要索引很长的字符串这会让索引变得很大查询时将浪费大量的磁盘IO 影响查询效率。此时可以只将字符串的一部分前缀建立索引这样可以大大节约索引空间从而提高索引效率。 6.7.2、语法 create index idx_xxxx on table_name(column(n)) ;示例为tb_user表的email字段建立长度为5的前缀索引
create index idx_email_5 on tb_user(email(5)); 6.7.3、前缀长度 可以根据索引的选择性来决定而选择性是指不重复的索引值基数和数据表的记录总数的比值索引选择性越高则查询效率越高 唯一索引的选择性是1这是最好的索引选择性性能也是最好的。 select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ; 6.7.4、前缀索引的查询流程 6.8、单列索引与联合索引
6.8.1、概述
单列索引即一个索引只包含单个列。 联合索引即一个索引包含了多个列。 6.8.2、当前tb_user表的索引情况
show index from tb_user; 在查询出来的索引中既有单列索引又有联合索引。 接下来执行一条SQL语句看看其执行计划
explain select id,phone,name from tb_user where phone 17799990010 and name 韩信; 分析通过上述执行计划可以看出来在and连接的两个字段 phone、name上都是有单列索引的但是最终mysql只会选择一个索引也就是说只能走一个字段的索引此时是会回表查询的效率不是最高。
在tb_user表中创建phone和name的联合索引后再次执行上述SQL观察结果
create unique index idx_user_phone_name on tb_user(phone,name); 在业务场景中如果存在多个查询条件考虑针对于查询字段建立索引时建议建立联合索引而非单列索引。6.8.3、联合索引执行示意图 七、索引设计原则
1、针对于数据量较大且查询比较频繁的表建立索引。 2、针对于常作为查询条件where、排序order by、分组group by操作的字段建立索引。 3、尽量选择区分度高的列作为索引尽量建立唯一索引区分度越高使用索引的效率越高。 4、如果是字符串类型的字段字段的长度较长可以针对于字段的特点建立前缀索引。 5、尽量使用联合索引减少单列索引查询时联合索引很多时候可以覆盖索引节省存储空间避免回表提高查询效率。 6、要控制索引的数量索引并不是多多益善索引越多维护索引结构的代价也就越大会影响增删改的效率。7、如果索引列不能存储NULL值请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含 NULL值时它可以更好地确定哪个索引最有效地用于查询。
