MySQL常见优化

1.操作符优化

1.1<> 操作符(不等于)

优化原因:
不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。 优化方法:
a): 用其它相同功能的操作运算代替,如 a<>0 改为 a>0 or a<0 a<>'' 改为 a>''
b): 尽量便面使用 != 操作符,如 c != '' 应写成 c > ''

1.2LIKE优化

优化方法:
a): LIKE '名称%'-----可以使用到索引,可以使用
b): LIKE '%名称%'----不会使用索引,尽量避免使用,只能在语句上进行优化
原SQL: Select object_id,object_type,object_name from t1
where object_name like '%ABC%'; 改写后的SQL:Select object_id ,object_type,object_name from t1
Where object_name in
(select object_name from t1 where object_name like '%ABC%');
c): LIKE '%名称'-----不会使用到索引,应优化
1: 首先,在查询的列建立反向索引
cerate index 索引名称 on 表名(reverse(列名));
2: 查询语句如下:
select count(*) from emp where reverse(列名) like reverse('%名称'); 用全文搜索搜索文本数据,取代like搜索
全文搜索始终优于like搜索:
(1)全文搜索让你可以实现like不能完成的复杂搜索,如搜索一个单词或一个短语,搜索一个与另一个单词或短语相近的单词或短语,或者是搜索同义词;
(2)实现全文搜索比实现like搜索更容易(特别是复杂的搜索);

1.3in,not in,exists与not exists

1.3.1in和exists

    in是把外表和内表作hash连接,而exists是对外表作loop循环,每次loop循环再对内表进行查询,一直以来认为exists比in效率高的说法是不准确的。
如果查询的两个表大小相当,那么用in和exists差别不大;如果两个表中一个较小一个较大,则子查询表大的用exists,子查询表小的用in; 例如:表A(小表),表B(大表)
select * from A where cc in(select cc from B)  -->效率低,用到了A表上cc列的索引;
select * from A where exists(select cc from B where cc=A.cc)  -->效率高,用到了B表上cc列的索引。 相反的:
select * from B where cc in(select cc from A)  -->效率高,用到了B表上cc列的索引
select * from B where exists(select cc from A where cc=B.cc)  -->效率低,用到了A表上cc列的索引。

Not IN 不走索引的是绝对不能用的,可以用NOT EXISTS 代替

2.where子句优化

2.1第一个原则:在where子句中应把最具限制性的条件放在最前面。

    在下面两条select语句中:
select * from table1 where field1<=10000 and field1>=0;
select * from table1 where field1>=0 and field1<=10000;
如果数据表中的数据field1都>=0,则第一条select语句要比第二条select语句效率高的多,
因为第二条select语句的第一个条件耗费了大量的系统资源。

2.2第二个原则:where子句中字段的顺序应和索引中字段顺序一致。

    在下面的select语句中:
select * from tab where a=… and b=… and c=…;
若有索引index(a,b,c),则where子句中字段的顺序应和索引中字段顺序一致。

2.3应尽量避免在 where 子句中使用 or 来连接条件,

如果一个字段有索引,一个字段没有索引,将导致引擎放弃使用索引而进行全表扫描,如:   
select id from t where num=10 or Name = 'admin'   
可以这样查询:   
select id from t where num = 10   
union all   
select id from t where Name = 'admin'

2.4应尽量避免在 where 子句中等号的左端对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:

    select id from t where num/2 = 100   
应改为:   
select id from t where num = 100*2

2.5在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,

否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。(不需要完全一致。最左前缀原则。)

以下假设在field1上有唯一索引I1,在field2上有非唯一索引I2。

      1):
a):
select field3,field4 from tb where field1='sdf' 快
select * from tb where field1='sdf' 慢,
因为后者在索引扫描后要多一步ROWID表访问。 b):
select field3,field4 from tb where field1>='sdf' 快
select field3,field4 from tb where field1>'sdf' 慢
因为前者可以迅速定位索引。 c):
select field3,field4 from tb where field2 like 'R%' 快
select field3,field4 from tb where field2 like '%R' 慢,
因为后者不使用索引。 2) 使用函数如:
select field3,field4 from tb where upper(field2)='RMN'不使用索引。
如果一个表有两万条记录,建议在WHERE子句中不使用函数;
如果一个表有五万条以上记录,在WHERE子句中严格禁止使用函数!两万条记录以下没有限制。

3.SQL语句注意事项

3.1在查询中不要使用select *

为什么不能使用,地球人都知道,但是很多人都习惯这样用,要明白能省就省,而且这样查询数据库不能利用“覆盖索引”了

3.2尽量写WHERE子句

尽量不要写没有WHERE的SQL语句

3.3注意SELECT INTO后的WHERE子句

因为SELECT INTO把数据插入到临时表,这个过程会锁定一些系统表,如果这个WHERE子句返回的数据过多或者速度太慢,会造成系统表长期锁定,诸塞其他进程。

3.4对于聚合查询,可以用HAVING子句进一步限定返回的行

3.5避免使用临时表

(1)除非却有需要,否则应尽量避免使用临时表,相反,可以使用表变量代替;

(2)大多数时候(99%),表变量驻扎在内存中,因此速度比临时表更快,临时表驻扎在TempDb数据库中,因此临时表上的操作需要跨数据库通信,速度自然慢。

3.6减少访问数据库的次数:

程序设计中最好将一些常用的全局变量表放在内存中或者用其他的方式减少数据库的访问次数

3.7尽量少做重复的工作

尽量减少无效工作,但是这一点的侧重点在客户端程序,需要注意的如下:

A、控制同一语句的多次执行,特别是一些基础数据的多次执行是很多程序员很少注意的

B、减少多次的数据转换,也许需要数据转换是设计的问题,但是减少次数是程序员可以做到的。

C、杜绝不必要的子查询和连接表,子查询在执行计划一般解释成外连接,多余的连接表带来额外的开销。

D、合并对同一表同一条件的多次UPDATE,比如

UPDATE EMPLOYEE SET FNAME=‘HAIWER’ WHERE EMP_ID=‘VPA30890F’

UPDATE EMPLOYEE SET LNAME=‘YANG’ WHERE EMP_ID=‘VPA30890F’

这两个语句应该合并成以下一个语句

UPDATE EMPLOYEE SET FNAME=‘HAIWER’,LNAME=‘YANG’

WHERE EMP_ID=’ VPA30890F’

E、UPDATE操作不要拆成DELETE操作+INSERT操作的形式,虽然功能相同,但是性能差别是很大的。

F、不要写一些没有意义的查询,比如

SELECT * FROM EMPLOYEE WHERE 1=2

MySQL常见优化的更多相关文章

  1. mysql常见优化,更多mysql,Redis,memcached等文章

    mysql常见优化 http://www.cnblogs.com/ggjucheng/archive/2012/11/07/2758058.html 更多mysql,Redis,memcached等文 ...

  2. mysql 性能优化常见命令

    mysql 性能优化常见命令: 一: 当发现mysql程序运行缓慢时,在排除sql主机问题之后,可以尝试在schema,table,和sql上进一步进行考查: 1:mysql> show ful ...

  3. MYSQL常见的可优化点

    MYSQL常见的可优化点 SQL常见的可优化点 2014年6月8日 DBA 发表回复 # #################################################### 索引 ...

  4. MySQL常见注意事项及优化

    MySQL常见注意事项 模糊查询 like 默认是对name字段建立了索引 注意:在使用模糊查询的时候,当% 在第一个字母的位置的时候,这个时候索引是无法被使用的.但是% 在其他的位置的时候,索引是可 ...

  5. Python进阶----索引原理,mysql常见的索引,索引的使用,索引的优化,不能命中索引的情况,explain执行计划,慢查询和慢日志, 多表联查优化

    Python进阶----索引原理,mysql常见的索引,索引的使用,索引的优化,不能命中索引的情况,explain执行计划,慢查询和慢日志, 多表联查优化 一丶索引原理 什么是索引:       索引 ...

  6. MySQL中的SQL的常见优化策略

    MySQL中的SQL的常见优化策略 MySQL中的索引优化 MySQL中的索引简介 1 避免全表扫描对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索 ...

  7. MySQL · 性能优化 · MySQL常见SQL错误用法(转自-阿里云云栖社区)

    作者:阿里云云栖社区链接:https://zhuanlan.zhihu.com/p/26043916来源:知乎著作权归作者所有,转载请联系作者获得授权. 前言 MySQL在2016年仍然保持强劲的数据 ...

  8. 「MySQL高级篇」explain分析SQL,索引失效&&常见优化场景

    大家好,我是melo,一名大三后台练习生 专栏回顾 索引的原理&&设计原则 欢迎关注本专栏:MySQL高级篇 本篇速览 在我们上一篇文章中,讲到了索引的原理&&设计原则 ...

  9. Mysql性能优化一

    下一篇:Mysql性能优化二 mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面进行优化,最终性能就会有大的提升. Mysql数据库的优化技术 对mysql优化是一个综合性的技术,主要包 ...

随机推荐

  1. Spark UDAF实现举例 -- average pooling

    目录 1.UDAF定义 2.向量平均(average pooling) 2.1 average的并行化 2.2 代码实现 2.3 使用 参考 1.UDAF定义 spark中的UDF(UserDefin ...

  2. DRF之访问权限控制和访问频率控制(节流)

    权限控制 前言 用户验证用户权限,根据不同访问权限控制对不同内容的访问. 建议了解视图.token验证的内容. 使用流程 自定义访问权限类,继承BasePermission,重写has_permiss ...

  3. BCC和libbpf的转换

    BCC和libbpf的转换 本文讲述如何将基于BCC的BPF应用转换为libbpf + BPF CO-RE.BPF CO-RE可以参见上一篇博文. 为什么是libbpf和BPF CO-RE? 历史上, ...

  4. JavaScript同步模式,异步模式及宏任务,微任务队列

    首先JavaScript是单线程的语言,也就是说JS执行环境中,负责执行代码的线程只有一个.一次只能执行一个任务,如果有多个任务的话, 就要排队,然后依次执行,优点就是更安全,更简单.缺点就是遇到耗时 ...

  5. flume基本概念及相关参数详解

    1.flume是分布式的日志收集系统,把手机来的数据传送到目的地去 2.flume传输的数据的基本单位是 event,如果是文本文件,通常是一行记录.       event代表着一个数据流的最小完整 ...

  6. 杭电OJ----1002A + B问题II(超大数计算问题)

    Problem Description I have a very simple problem for you. Given two integers A and B, your job is to ...

  7. 字典实现:python-----VS----java

    对比python和java的字典数据结构,以下就LeetCode面试题 17.10. 主要元素为栗子,进行学习.是一道简单题目,重点看数据结构的运用与实现. 普通的思路,使用一个字典结构记录每个元素出 ...

  8. 最全的HashMap源码解析!

    HashMap源码解析 HashMap采用键值对形式的存储结构,每个key对应唯一的value,查询和修改的速度很快,能到到O(1)的平均复杂度.他是非线程安全的,且不能保证元素的存储顺序. 他的关系 ...

  9. (二)数据源处理5-excel数据转换实战(上)

    把excel_oper02.py 里面实现的:通过字典的方式获取所有excel数据.放进utils: ️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️ utils: def get_al ...

  10. 【Jboss】A RESOURCE POOL IS PERMANENTLY BROKEN!

    jboss后台报错,其中有这个错误 [error] A RESOURCE POOL IS PERMANENTLY BROKEN! 查阅多方资料后发现.数据库连接配置文件中,有地方存在空格,导致服务连接 ...