请选择 进入手机版 | 继续访问电脑版
  • 关注官方微信 微信公众号 添加方式:
    1:搜索微信号(gogolinux
    2:扫描左侧二维码
  • 登录 注册
  • 一起学LINUX - GOGOLINUX

    查看: 749|回复: 0

    19个MySQL优化技巧,索引优化这样做最有效!

    [复制链接]

    2

    主题

    2

    帖子

    20

    积分

    新手上路

    Rank: 1

    积分
    20
    发表于 2020-4-27 17:46:51 | 显示全部楼层 |阅读模式
    - 点击上方“中国统计网”订阅我吧!-
    声明:下面的优化方案都是基于“ Mysql-索引-BTree类型 ”
    善用EXPLAIN做MySQL优化,我们要善用EXPLAIN查看SQL执行计划
    下面来个简单的示例,标注(1,2,3,4,5)我们要重点关注的数据:

    1. type列:连接类型
    一个好的sql语句至少要达到range级别,杜绝出现all级别。
    2. key列:使用到的索引名
    如果没有选择索引,值是NULL,可以采取强制索引方式。
    3. key_len列:索引长度
    4. rows列:扫描行数
    该值是个预估值。
    5. Extra列:详细说明
    注意常见的不太友好的值有:Using filesort, Using temporary
    MySQL对于IN做了相应的优化,即将IN中的常量全部存储在一个数组里面,而且这个数组是排好序的。但是如果数值较多,产生的消耗也是比较大的。
    再例如:select id from table_name where num in(1,2,3)对于连续的数值,能用 between 就不要用 in 了;再或者使用连接来替换。
    SELECT * 增加很多不必要的消耗(cpu、io、内存、网络带宽),增加了使用覆盖索引的可能性,当表结构发生改变时,前端也需要更新。所以要求直接在select后面接上字段名
    只需要一条数据的时候当只需要一条数据的时候,使用limit 1,这是为了使EXPLAIN中type列达到const类型。
    没有索引的排序如果排序字段没有用到索引,就尽量少排序
    如果限制条件中其他字段没有索引,尽量少用or
    or两边的字段中,如果有一个不是索引字段,而其他条件也不是索引字段,会造成该查询不走索引的情况。很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。
    union和union all的差异主要是前者需要将结果集合并后再进行唯一性过滤操作,这就会涉及到排序,增加大量的CPU运算,加大资源消耗及延迟。当然,union all的前提条件是两个结果集没有重复数据
    selectidfrom'table_name't1join(selectrand * (selectmax(id)from'table_name')asnid) t2ont1.id > t2.nidlimit1000;select * from 表Awhere exists (select * from 表B where 表B.id=表A.id)区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键),如果是exists,那么以外层表为驱动表,先被访问,如果是IN,那么先执行子查询。所以IN适合于外表大而内表小的情况;EXISTS适合于外表小而内表大的情况。关于not in和not exists,推荐使用not exists,不仅仅是效率问题,not in可能存在逻辑问题。
    如何高效的写出一个替代not exists的sql语句?
    selectcolname …fromA表

    • 高效的sql语句:
    select colname … from A表 Left join B表 onwhere a.id = b.id where b.id is null取出的结果集如下图表示,A表不在B表中的数据。

    selectid,namefromtable_namelimit866613,20使用上述sql语句做分页的时候,可能有人会发现,随着表数据量的增加,直接使用limit分页查询会越来越慢。

    优化的方法如下:可以取前一页的最大行数的id,然后根据这个最大的id来限制下一页的起点。比如此列中,上一页最大的id是866612。sql可以采用如下的写法:
    select id,name from table_namewhere id > 866612 limit 20分段查询在一些用户选择页面中,可能一些用户选择的时间范围过大,造成查询缓慢。主要的原因是扫描行数过多。这个时候可以通过程序分段进行查询,循环遍历,将结果合并处理进行展示。
    如下图这个sql语句,扫描的行数成百万级以上的时候就可以使用分段查询:

    对于null的判断会导致引擎放弃使用索引而进行全表扫描。
    不建议使用%前缀模糊查询例如LIKE “%name”或者LIKE “%name%”,这种查询会导致索引失效而进行全表扫描。但是可以使用LIKE “name%”。
    那如何查询%name%?
    如下图所示,虽然给secret字段添加了索引,但在explain结果并没有使用。

    那么如何解决这个问题呢?答案:使用全文索引
    在我们查询中经常会用到select id,fnum,fdst from table_name where user_name like '%zhangsan%'; 这样的语句,普通索引是无法满足查询需求的。庆幸的是在MySQL中,有全文索引来帮助我们。

    • 创建全文索引的sql语法是:
    ALTER TABLE 'table_name' ADD FULLTEXTINDEX 'idx_uesr_name' ('user_name');

    • 使用全文索引的sql语句是:
    select id,fnum,fdst from table_namewhere match(user_name) against('zhangsan' in booleanmode);注意:在需要创建全文索引之前,请联系DBA确定能否创建。同时需要注意的是查询语句的写法与普通索引的区别。
    whereage*2=36;对字段就进行了算术运算,这会造成引擎放弃使用索引,建议改成:
    select user_id,user_project from table_name
    where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换,建议先确定where中的参数类型

    遵守最左前缀法则对于联合索引来说,要遵守最左前缀法则。
    举列来说索引含有字段id,name,school,可以直接用id字段,也可以id,name这样的顺序,但是name;school都无法使用这个索引。
    所以在创建联合索引的时候一定要注意索引字段顺序,常用的查询字段放在最前面。
    必要时可以使用force index来强制查询某个索引。
    有的时候MySQL优化器采取它认为合适的索引来检索sql语句,但是可能它所采用的索引并不是我们想要的。这时就可以采用force index来强制优化器使用我们制定的索引。
    注意范围查询语句
    对于联合索引来说,如果存在范围查询,比如between,>,

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?立即注册

    x
    分享到:
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    官方微博:

    官方头条号:

    官方微信

    手机访问:

    官方微信

    QQArchiver 手机版 小黑屋 一起学LINUX - GOGOLINUX 闽ICP备18025837号-1 Discuz! X3.4 Powered by © 2001-2013 Comsenz Inc. 

    本站资源均来自互联网或会员发布,如果侵犯了您的权益请与我们联系,我们将在24小时内删除!谢谢!

    快速回复 快速发帖 返回顶部 返回列表