神奇的 SQL 之擦肩而过 → 真的用到索引了吗
开心一刻
今天下班,骑着青桔电动车高高兴兴的哼着曲回家,感觉整个世界都是我的
刚到家门口,还未下车,老妈就气冲冲的走过来对我说道:“你表哥就比你大一岁,人家都买了奔驰了,50 多万!”
我:“表哥那车,舅舅出了 40 多万”
老妈:“那不还有 10 多万是他自己出的”
我:“那 10 几万是他丈母娘出的”
老妈:“你还有脸说,你连个对象都没有!”
老妈走回家,回头望了眼我胯下的青桔,一脸不屑地说道:“连个自行车都没有”
我:“这是电动车!”
老妈:“那也不是你的”
我低头望了望青桔,差点一脚把它踹开,可想了想,踹坏了赔不起,赶紧找个停车点把车停好吧,不然又多扣五毛钱了
索引的数据结构
什么是数据库索引 ,相信大家都能答上来,索引就是为了加速对表中数据行的检索而创建的一种分散存储的数据结构(索引是一种数据结构)
但具体是什么样的数据结构,很多小伙伴可能就不知道了
索引的数据结构包括 哈希表、B树、B+树 等,而用的最多的就是 B+树
我们以 MySQL 为例,来看看 B+树 结构的索引到底是什么样的
表: tbl_index
CREATE TABLE tbl_index (
c1 INT,
c2 INT,
c3 CHAR(1),
PRIMARY KEY(c1),
KEY idx_c2 (c2)
);
c1 上有聚簇索引, c2 上有二级索引(即非聚簇索引)
InnoDB 的索引
InnoDB 下的聚簇索引 和 二级索引还是有区别的
MyISAM 的索引
MyISAM 聚簇索引和二级索引结构基本一致,只是聚簇索引有个唯一性约束
B+树 就是如上图中的那样一个倒立的树结构
B+树 有很多特性,这里就不细讲了,有兴趣的可以去查阅相关资料
组合索引的列顺序
单列索引的列顺序好说,它就一列,不存在列先后顺序的问题,按这个列的值进行顺序排序,存储到 B+树 中就好,上面两图都是单列索引
但在实际应用中,更多的还是用到组合索引(在多列上建一个索引),既然有多列,那就存在列与列之间的顺序问题了
那组合索引的的结构具体是什么样的了?
我们有表: tbl_group_index ,在 c2 列和 c3 列上建一个组合索引 idx_c2_c3
CREATE TABLE tbl_group_index (
c1 INT,
c2 INT,
c3 CHAR(1),
c4 INT,
PRIMARY KEY(c1),
KEY idx_c2_c3 (c2,c3)
);
那么,索引 idx_c2_c3 的结构如下
先按 c1 列排序,若 c1 列相等了再按 c2 列排序
抽象化就是,按组合索引指定的列,从左往右逐个排序;整体上先按第一列排序,第一列相等的数据整体按第二列排序,第一列相等且第二列相等的数据整体按第三列排序,以此类推
索引的擦肩而过
有的小伙伴可能急了:“楼主,前戏太多了,我要看主角!!!”
楼主:“你怕是个杠精吧,前戏不写长点,怎么凑够篇幅? 你去看看现在的动漫,哪个不是正戏不够前戏来扣?(更可恶的是还有一大截尾戏拼凑)”
好了,不多扯了(再扯楼主怕是有生命危险了),我们一起来看看今天的主角们!
环境准备
MySQL 版本: 5.7.30-log ,存储引擎: InnoDB
准备表: tbl_customer_recharge_record ,并初始化 7 条数据
DROP TABLE IF EXISTS tbl_customer_recharge_record;
CREATE TABLE tbl_customer_recharge_record (
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
customer_id INT(11) NOT NULL COMMENT '顾客ID',
customer_name VARCHAR(50) NOT NULL COMMENT '顾客姓名',
recharge_type TINYINT(2) NOT NULL COMMENT '充值方式 1:支付宝, 2:微信,3:QQ,4:京东,5:银联,6:信用卡,7:其他',
recharge_amount DECIMAL(15,2) NOT NULL COMMENT '充值金额, 单位元',
recharge_time DATETIME NOT NULL COMMENT '充值时间',
remark VARCHAR(500) NOT NULL DEFAULT 'remark' COMMENT '备注',
PRIMARY KEY (id),
KEY idx_c_id(customer_id),
KEY idx_name_type_time(customer_name,recharge_type,recharge_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='顾客充值记录表'; INSERT INTO tbl_customer_recharge_record(customer_id, customer_name,recharge_type,recharge_amount,recharge_time) VALUES
(1,'李小龙',1,10000,NOW()),
(2,'李连杰',2,20000,NOW()),
(1,'李小龙',2,10000,NOW()),
(1,'李小龙',3,10000,NOW()),
(2,'李连杰',7,20000,NOW()),
(3,'成龙',3,15000,NOW()),
(1,'李小龙',1,10000,NOW());
一共有 3 个索引:
id 列上的聚簇索引
customer_id 列上的二级索引: idx_c_id
以及 customer_name,recharge_type,recharge_time 列上的组合索引: idx_name_type_time
后面我们会用 EXPLAIN 来查看执行计划,查看索引使用情况,对它还不熟的小伙伴,赶紧点进去先看看
全表扫描更优
这是什么意思了,就是说优化器在进行优化的时候,会从众多可选的执行计划中选择它认为最优的那一个
当优化器计算得出通过全表查询比通过索引查询更优时,它会选择全表扫描的方式进行查询
SQL: explain select * from tbl_customer_recharge_record where customer_id = 2;
相信大家对这个没什么异议,通过 idx_c_id 来完成查询,跟我们预想的一样
对于 explain select * from tbl_customer_recharge_record where customer_id = 1; 大家睁大眼睛看清楚了啊!
能用的索引包括: idx_c_id ,但实际没用它,而是走的全表查询;因为优化器认为走全表查询成本更低,查询更快
MySQL5.6 新引入的一项跟踪功能: OPTIMIZER_TRACE ,可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等)
并将跟踪结果记录到 INFORMATION_SCHEMA.OPTIMIZER_TRACE 中
跟踪功能默认是关闭的,我们要用它的话,需要将其开启: set optimizer_trace='enabled=on';
查看优化器优化步骤: select * from information_schema.OPTIMIZER_TRACE;
优化器对 select * from tbl_customer_recharge_record where customer_id = 1; 优化步骤如下
{
"steps":[
{
"join_preparation":{
"select#":1,
"steps":[
{
"expanded_query":"/* select#1 */ select `tbl_customer_recharge_record`.`id` AS `id`,`tbl_customer_recharge_record`.`customer_id` AS `customer_id`,`tbl_customer_recharge_record`.`customer_name` AS `customer_name`,`tbl_customer_recharge_record`.`recharge_type` AS `recharge_type`,`tbl_customer_recharge_record`.`recharge_amount` AS `recharge_amount`,`tbl_customer_recharge_record`.`recharge_time` AS `recharge_time`,`tbl_customer_recharge_record`.`remark` AS `remark` from `tbl_customer_recharge_record` where (`tbl_customer_recharge_record`.`customer_id` = 1)"
}
]
}
},
{
"join_optimization":{
"select#":1,
"steps":[
{
"condition_processing":{
"condition":"WHERE",
"original_condition":"(`tbl_customer_recharge_record`.`customer_id` = 1)",
"steps":[
{
"transformation":"equality_propagation",
"resulting_condition":"multiple equal(1, `tbl_customer_recharge_record`.`customer_id`)"
},
{
"transformation":"constant_propagation",
"resulting_condition":"multiple equal(1, `tbl_customer_recharge_record`.`customer_id`)"
},
{
"transformation":"trivial_condition_removal",
"resulting_condition":"multiple equal(1, `tbl_customer_recharge_record`.`customer_id`)"
}
]
}
},
{
"substitute_generated_columns":{ }
},
{
"table_dependencies":[
{
"table":"`tbl_customer_recharge_record`",
"row_may_be_null":false,
"map_bit":0,
"depends_on_map_bits":[ ]
}
]
},
{
"ref_optimizer_key_uses":[
{
"table":"`tbl_customer_recharge_record`",
"field":"customer_id",
"equals":"1",
"null_rejecting":false
}
]
},
{
"rows_estimation":[
{
"table":"`tbl_customer_recharge_record`",
"range_analysis":{
"table_scan":{
"rows":7,
"cost":4.5
},
"potential_range_indexes":[
{
"index":"PRIMARY",
"usable":false,
"cause":"not_applicable"
},
{
"index":"idx_c_id",
"usable":true,
"key_parts":[
"customer_id",
"id"
]
},
{
"index":"idx_name_type_time",
"usable":false,
"cause":"not_applicable"
}
],
"setup_range_conditions":[ ],
"group_index_range":{
"chosen":false,
"cause":"not_group_by_or_distinct"
},
"analyzing_range_alternatives":{
"range_scan_alternatives":[
{
"index":"idx_c_id",
"ranges":[
"1 <= customer_id <= 1"
],
"index_dives_for_eq_ranges":true,
"rowid_ordered":true,
"using_mrr":false,
"index_only":false,
"rows":4,
"cost":5.81,
"chosen":false,
"cause":"cost"
}
],
"analyzing_roworder_intersect":{
"usable":false,
"cause":"too_few_roworder_scans"
}
}
}
}
]
},
{
"considered_execution_plans":[
{
"plan_prefix":[ ],
"table":"`tbl_customer_recharge_record`",
"best_access_path":{
"considered_access_paths":[
{
"access_type":"ref",
"index":"idx_c_id",
"rows":4,
"cost":2.8,
"chosen":true
},
{
"rows_to_scan":7,
"access_type":"scan",
"resulting_rows":7,
"cost":2.4,
"chosen":true
}
]
},
"condition_filtering_pct":100,
"rows_for_plan":7,
"cost_for_plan":2.4,
"chosen":true
}
]
},
{
"attaching_conditions_to_tables":{
"original_condition":"(`tbl_customer_recharge_record`.`customer_id` = 1)",
"attached_conditions_computation":[ ],
"attached_conditions_summary":[
{
"table":"`tbl_customer_recharge_record`",
"attached":"(`tbl_customer_recharge_record`.`customer_id` = 1)"
}
]
}
},
{
"refine_plan":[
{
"table":"`tbl_customer_recharge_record`"
}
]
}
]
}
},
{
"join_execution":{
"select#":1,
"steps":[ ]
}
}
]
}
内容有点多,我们只关注
{
"considered_execution_plans":[
{
"plan_prefix":[ ],
"table":"`tbl_customer_recharge_record`",
"best_access_path":{
"considered_access_paths":[
{
// 走索引 idx_c_id,花费成本 2.8
"access_type":"ref",
"index":"idx_c_id",
"rows":4,
"cost":2.8,
"chosen":true
},
{
// 走全表,花费成本 2.4
"rows_to_scan":7,
"access_type":"scan",
"resulting_rows":7,
"cost":2.4,
"chosen":true
}
]
},
// 对比下来,最终选择花费成本更低的全表扫描
"condition_filtering_pct":100,
"rows_for_plan":7,
"cost_for_plan":2.4,
"chosen":true
}
]
}
相比于使用索引,全表扫描效率更高,那为什么还选择索引呢?
LIKE 进行后方一致或中间一致的匹配
说的更通俗一点,就是以 % 开头进行匹配
如果 LIKE 进行前方一致匹配,索引还是会生效的
SQL: explain select * from tbl_customer_recharge_record where customer_name like '成%';
如果以 % 开头进行匹配,则不会用到索引
SQL: explain select * from tbl_customer_recharge_record where customer_name like '%杰';
OR 前后未同时使用索引
数据量太少,优化器会选择全表扫描,而不走索引了,我们再加点数据
INSERT INTO tbl_customer_recharge_record(customer_id, customer_name,recharge_type,recharge_amount,recharge_time) VALUES
(1,'李小龙',1,10000,NOW()),
(2,'李连杰',2,20000,NOW()),
(3,'成龙',3,15000,NOW()),
(4,'吴京',5,500,NOW()),
(5,'吴越',4,200,NOW()),
(6,'张晋',6,100,NOW()),
(7,'梁小龙',7,2000,NOW()),
(8,'释小龙',1,3000,NOW()),
(9,'甄子丹',2,4000,NOW()),
(10,'元彪',3,5000,NOW()),
(11,'钱嘉乐',4,5000,NOW()),
(12,'钱小豪',5,5000,NOW()),
(13,'洪金宝',6,5000,NOW()),
(14,'刘家良',6,5000,NOW()),
(15,'刘家辉',5,5000,NOW()),
(16,'邹兆龙',4,5000,NOW()),
(17,'林国斌',3,5000,NOW()),
(18,'赵文卓',2,5000,NOW()),
(19,'于荣光',1,5000,NOW()),
(20,'杨紫琼',1,5000,NOW()),
(1,'李小龙',1,5000,NOW()),
(2,'李连杰',2,5000,NOW()),
(3,'成龙',2,5000,NOW()),
(13,'洪金宝',2,5000,NOW()),
(9,'甄子丹',1,5000,NOW()),
(20,'杨紫琼',1,5000,NOW()),
(18,'赵文卓',1,5000,NOW()),
(11,'钱嘉乐',1,5000,NOW()),
(16,'邹兆龙',1,5000,NOW()),
(19,'于荣光',1,5000,NOW());
OR 前后都能用到索引的话,还是会走索引查询的
只要 OR 前后有一个走不了索引,那就会全表扫描了
组合索引,未遵循最左匹配原则
最左匹配指的是,按组合索引指定的列顺序,从左往右逐个列匹配,像这样
不能直接跨过前面的列,否则就不能用到索引了
强烈建议:组合索引中的第一列必须写在查询条件的开头,而且索引中列的顺序不能颠倒
虽说有些数据库(例如 MySQL)里顺序颠倒后也能使用索引(优化器会优化列顺序来适配索引),但是性能还是比顺序正确时差一些
至于为什么要遵从最左匹配原则,大家可以结合前面讲过的组合索引的数据结构来分析(还觉得我前戏太多吗,啊!)
使用否定形式
否定形式包括:<>, !=, NOT IN,NOT EXIST,会导致全表扫描
索引列上进行运算
说的更准确点,是在查询条件的左侧进行运算,这种情况就不能用索引了
在查询条件的右侧进行计算,还是能用到索引的
索引列上使用函数
说的更准确点,是在查询条件的左侧使用函数,这种情况就不能用索引了
在右侧使用函数,还是能用到索引的
强烈建议:使用索引时,条件表达式的左侧应该是原始列
进行默认的类型转换
新建表: tbl_char ,并初始化 7 条数据
DROP TABLE IF EXISTS tbl_char;
CREATE TABLE tbl_char (
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
type CHAR(1) NOT NULL,
name VARCHAR(50),
PRIMARY KEY (id),
KEY idx_type(type),
KEY idx_name(name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO tbl_char(type, name) VALUES
('1',null),
('2','1'),
('3','2'),
('4',null),
('5','5'),
('6','6'),
('7','7');
type 的类型是 char
SQL: explain select * from tbl_char where type = 2;
默认的类型转换不仅会增加额外的性能开销,还会导致索引不可用,可以说是有百害而无一利
(对于 int 类型的列,传字符串类型的值是可以走索引的,MySQL 内部自动做了隐式类型转换;相反,对于 char 或 varchar 类型的列,传入 int 值是无法走索引的)
强烈建议:使用索引时,条件表达式的右侧常数的类型应该与列类型保持一致
IS NULL 与 IS NOT NULL
我做个简单的测试,就不下结论了
SQL: explain select * from tbl_char where name is not null;
SQL: explain select * from tbl_char where name is null;
强烈建议:所有列都指定 NOT NULL 和默认值
NULL 的陷阱太多,详情可查看:神奇的 SQL 之温柔的陷阱 → 三值逻辑 与 NULL !
不走索引的情况,文中只列举了常见的部分,还有其他的场景未列举,欢迎小伙伴们补充
总结
1、索引数据结构
索引的数据结构包括 哈希表、B树、B+树 等,而用的最多的就是 B+数
2、未走索引的常见场景
全表扫描优于索引扫描
LIKE 进行后方一致或中间一致的匹配
OR 前后未同时使用索引
组合索引,未遵循最左匹配原则
进行默认的类型转换
使用否定形式
索引列上进行运算
索引列上使用函数
3、推荐做法
使用组合索引时,组合索引中的第一列必须写在查询条件的开头,而且索引中列的顺序不能颠倒
使用索引时,条件表达式的左侧应该是原始列,右侧是常数且类型与左侧列一致,左右侧都不参与计算、使用函数(计算、函数运算、逻辑处理都交由专门的开发语言去实现)
所有列都指定 NOT NULL 和默认值,避免 NULL 的陷阱
参考
《SQL进阶教程》
神奇的 SQL 之温柔的陷阱 → 三值逻辑 与 NULL !
神奇的 SQL 之擦肩而过 → 真的用到索引了吗的更多相关文章
- 神奇的 SQL 之性能优化 → 让 SQL 飞起来
开心一刻 一天,一个男人去未婚妻家玩,晚上临走时下起了大雨 未婚妻劝他留下来过夜,说完便去准备被褥,准备就绪后发现未婚夫不见了 过了好久,全身淋的像只落汤鸡的未婚夫回来了 未婚妻吃惊的问:" ...
- 神奇的 SQL 之别样的写法 → 行行比较
开心一刻 昨晚我和我爸聊天 我:"爸,你怎么把烟戒了,也不出去喝酒了,是因为我妈不让,还是自己醒悟,开始爱惜自己啦?" 爸:"儿子啊,你说的都不对,是彩礼又涨价了.&qu ...
- update值与原值相同时,SQL Server会真的去update还是忽略呢?
原文:update值与原值相同时,SQL Server会真的去update还是忽略呢? 考虑下面的情况: 当update值与原值相同时,SQL Server会真的去update还是忽略?例如: upd ...
- 神奇的 SQL 之谓词 → 难理解的 EXISTS
前言 开心一刻 我要飞的更高,飞的更高,啊! 谓词 SQL 中的谓词指的是:返回值是逻辑值的函数.我们知道函数的返回值有可能是数字.字符串或者日期等等,但谓词的返回值全部是逻辑值(TRUE/FALSE ...
- 神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(二)
开心一刻 一头母牛在吃草,突然一头公牛从远处狂奔而来说:“快跑啊!!楼主来了!” 母牛说:“楼主来了关我屁事啊?” 公牛急忙说:“楼主吹牛逼呀!” 母牛大惊,拔腿就跑,边跑边问:“你是公牛你怕什么啊? ...
- 神奇的 SQL 之 WHERE 条件的提取与应用
开心一刻 小明:为什么中国人结婚非要选一个好日子呢 ? 楼主:嗯 ? 那肯定啊,结完婚之后你还能有好日子吗 ? 小明:那结婚时所说的白头到老是真的吗 ? 楼主:这哪能是真的,你看现在,头发还没白就秃了 ...
- 神奇的 SQL 之 ICP → 索引条件下推
开心一刻 楼主:来,我们先排练一遍 小伙伴们:好 嘿.哈.嚯 楼主:非常好,就是这个节奏,我们开始吧 楼主:啊.啊.啊,疼 ! 你们是不是故意的 ? 回表与覆盖索引 正式讲 ICP 之前了,我们先将相 ...
- 神奇的 SQL 之扑朔迷离 → ON 和 WHERE,好多细节!
开心一刻 楼主:心都让你吓出来了! 狮王:淡定,打个小喷嚏而已 前情回顾 神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(一)中,我们讲到了 3 种联表算法:SNL.BNL 和 I ...
- 神奇的 SQL 之 HAVING → 容易被轻视的主角
开心一刻 一天,楼主和隔壁小男孩一起坐电梯,中途进来一位高挑的美女,她牵着一条雪白的贵宾犬 小男孩看着这条雪白的贵宾犬,甚是喜欢,说道:阿姨,我能摸下这个狗狗吗? 美女:叫姐姐 小男孩低头看了下贵宾犬 ...
随机推荐
- sentinel降级误解
public void initDegradeRule(){ List<DegradeRule> rules=new ArrayList<>(); DegradeRule ru ...
- kafka入门之broker-水印和leader epoch
每个kafka副本对象都持有2个重要的属性:日志末端位移LEO,高水印HW Kafka对leader副本和follower副本的LEO更新机制是不同的,后面我们会详细讨论. Kafka对leader副 ...
- 阿里云ECS服务器连接MongoDB
第一次接触MongoDB,第一次部署.将一些步骤整理出来,希望以后会用到,也希望能帮组到有这方面需求的小伙伴. 设备说明: 服务器为阿里云ECS服务器,网络为专有网络VPC,Mango为买的阿里云Ma ...
- eclispe中打点不会提示的解决方法,以及自动补全
Eclipse中打点无提示的解决办法 建了个JAVA工程,然后发现输入代码后,在输入.后面不会弹出来我所要的函数. alt+/ 提示No Default Proposals 自己找了半天, ...
- PyQt(Python+Qt)学习随笔:QScrollBar以及QAbstractSlider滚动条部件功能详解
专栏:Python基础教程目录 专栏:使用PyQt开发图形界面Python应用 专栏:PyQt入门学习 老猿Python博文目录 老猿学5G博文目录 一.概述 在Designer输入部件中Horizo ...
- PyQt(Python+Qt)学习随笔:QTreeView树形视图的animated属性
老猿Python博文目录 专栏:使用PyQt开发图形界面Python应用 老猿Python博客地址 QTreeView树形视图的animated属性用于控制视图在展开或收缩分支时是否展示动画,如果对应 ...
- Python & PyQt学习随笔:PyQt主程序的基本框架
在完成UI设计将UI通过PyUic转成Py文件后,由于这个生成的文件每次通过PyUic生成时都会被覆盖,因此应用的主程序必须另外单独编写py文件.需要将UI生成的文件import到主程序的py文件中. ...
- 孪生网络入门(下) Siamese Net分类服装MNIST数据集(pytorch)
主题列表:juejin, github, smartblue, cyanosis, channing-cyan, fancy, hydrogen, condensed-night-purple, gr ...
- ATT&CK 实战 - 红日安全 vulnstack (二) 环境部署(劝退水文)
靶机下载地址:http://vulnstack.qiyuanxuetang.net/vuln/detail/3/ 靶场简述 红队实战系列,主要以真实企业环境为实例搭建一系列靶场,通过练习.视频教程.博 ...
- 哀悼疫情,全站灰色如何实现,CSS滤镜一行代码实现
庚子清明,以国家之名哀悼,以国家之名哀悼在新冠肺炎疫情中牺牲的烈士和逝世的同胞! 向抗疫英雄致敬! 今日打开各样的app,各大电商,爱奇艺都是灰色的 这里我也一直很好奇该功能,前端如何实现,了解过后发 ...