首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >MySQL -通过调整索引提升查询效率

MySQL -通过调整索引提升查询效率

作者头像
用户3479834
发布2021-02-03 14:44:45
发布2021-02-03 14:44:45
5.1K0
举报
文章被收录于专栏:游戏开发司机游戏开发司机

我们遇到的最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询,并且同时需要考虑如何更好地满足排序和分组的需要(顺便说明,本节内容适用于B-Tree索引;哈希或者其他类型的索引并不会像B-Tree索引一样按顺序存储数据)。 在一个多列B-Tree索引中,索引列的顺序意味着索引首先按照最左列进行排序,其次是第二列,等等。所以,索引可以按照升序或者降序进行扫描,以满足精确符合列顺序的ORDER BY、GROUP BY和DISTINCT等子句的查询需求。 所以多列索引的顺序至关重要。在“三星索引”系统中,列顺序也决定了一个索引是否能够成为一个真正的“三星索引”。 对于如何选择索引的列顺序有一个经验法则:将选择性最高的列放到索引最前列。这个建议有用吗?在某些场景可能有帮助,但通常不如避免随机IO和排序那么重要,考虑问题需要更全面(场景不同则选择不同,没有一个放之四海皆准的法则。这里只是说明,这个经验法则可能没有你想象的重要)。 当不需要考虑排序和分组时,将选择性最高的列放在前面通常是很好的。这时候索引的作用只是用于优化WHERE条件的查找。在这种情况下,这样设计的索引确实能够最快地过滤出需要的行,对于WHERE子句中只使用了索引部分前缀列的查询来说选择性也更高。然而,性能不只是依赖于所有索引列的选择性(整体基数),也和查询条件的具体值有关,也就是和值的分布有关。这和选择前缀的长度需要考虑的地方一样。可能需要根据那些运行频率最高的查询来调整索引列的顺序,让这种情况下索引的选择性最高。

一个文章库,里面有两个表:category和article。category里面有10条分类数据。article里面有20万条。article里面有一个"article_category"字段是与category里的"category_id"字段相对应的。article表里面已经把 article_category字义为了索引。数据库大小为1.3G。 问题描述: 执行一个很普通的查询:SELECT * FROM `article` WHERE article_category=11 ORDER BY article_id DESC LIMIT 5 。执行时间大约要5秒左右 解决方案: 建一个索引:create index idx_u on article (article_category,article_id); SELECT * FROM `article` WHERE article_category=11 ORDER BY article_id DESC LIMIT 5 减少到0.0027秒 继续问题: SELECT * FROM `article` WHERE article_category IN (2,3) ORDER BY article_id DESC LIMIT 5 执行时间要11.2850秒。 使用OR: select * from article where article_category=2 or article_category=3 order by article_id desc limit 5 执行时间:11.0777 解决方案:避免使用in 或者 or (or会导致扫表),使用union all 使用UNION ALL: (select * from article where article_category=2 order by article_id desc limit 5) UNION ALL (select * from article where article_category=3 order by article_id desc limit 5) ORDER BY article_id desc limit 5 执行时间:0.0261 注:UNION 和UNION ALL 的区别

在 数据库中,UNION和UNION ALL关键字都是将两个结果集合并为一个,但这两者从使用和效率上来说都有所不同。 UNION在进行表链接后会筛选掉重复的记录,所以在表链接后会对所产生的结果集进行排序运算,删除重复的记录再返回结果。 实际大部分 应用中是不会产生重复的记录,最常见的是过程表与历史表UNION。如: select * from gc_dfys union select * from ls_jg_dfys 这个 SQL在运行时先取出两个表的结果,再用排序空间进行排序删除重复的记录,最后返回结果集,如果表数据量大的话可能会导致用磁盘进行排序。 而UNION ALL只是简单的将两个结果合并后就返回。这样,如果返回的两个结果集中有重复的数据,那么返回的结果集就会包含重复的数据了。 从效率上说,UNION ALL 要比UNION快很多,所以,如果可以确认合并的两个结果集中不包含重复的数据的话,那么就使用UNION ALL,如下: select * from gc_dfys union all select * from ls_jg_dfys 注: mysql中union all的order by问题

今天写mysql数据库代码的时候,发现union的结果不是预期的

stime = date("H:i:s"); stime'>stime order by stime desc"; stime' order by stime asc"; sql) union all (sql2)";

分别执行sql1 和 sql2 的时候结果是对的

但是执行sql的时候,发现结果反了,sql1的部分变升序,

搜索也没有得到满意的答案,好像有些数据库还是不支持字句order by 的

无意中发现这样可以,

sql = "select * from (

这是因为你的union的用法不正确的原因。在union操作中,order by语句不能出现在由union操作组合的两个select语句中。排序可以通过在第二个select语句后指定order by子句。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-12-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 游戏开发司机 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档