Mysql查询优化-DB篇

本文重点从数据库本身角度,硬件和环境的优化不在本文范围内

 


1. 使用索引(Index All Columns Used in 'where', 'order by', and 'group by' Clauses)

   索引的作用就不用在这里说了,需要说明的是其副作用:索引会占用更多的空间,并导致增删改速度会变慢

   一个很重要的问题是,如果建立索引之后,发现查询速度并没有加快,那么如果去排查呢?这就需要借助于执行计划(execution plan)了

   下面是建立索引前后的执行计划:

 explain SELECT title, body FROM test.articles where title ='数据库管理'
 建索引前:

  

   建立索引:ALTER TABLE articles ADD INDEX index_title (title)

   建索引后:

 

  索引是否有效,不只需要确认执行计划中的key,而且需要确认key_len

  比如此处的title是varchar(200),而且表的编码为utf8mb4(兼容性好于utf8),一个字符占4个字节,key_len=200*4 + 1(标示是否NULL) + 2(长度) 

  索引的数据结构:

  Mysql的索引使用的是B+二叉树(进一步,需要了解二叉树,平衡二叉树或者AVL树,红黑树,B/B+树

  B+树索引并不能找到一个给定键值的具体行,它找到的只是被查找数据行所在的页,接着数据库会把页读入到内存,再在内存中进行查找,最后得到要查找的数据。

 

  **对于连接查询,只需要在关联顺序中的第二张表的相应列上创建索引即可。

  **覆盖索引(包含所有需要查询的字段的值)对于字段少的查询非常有用

  **应避免冗余和重复索引,参考

  **不支持函数索引,但支持前缀索引(也就是对前N个字符创建索引)

  **列的基数(比如数值范围)越大,索引效果越好

  **尽量使用短索引

  **利用最左前缀:例如 ALTER TABLE student ADD INDEX lname_birth_age (name,birthday,age); 相当于建立了三个索引:(name),(name,birthday),(name,birthday,age),所以要把常用的放在最左边

 


2.  用Union代替like(Optimize Like Statements With Union Clause)

    如果是分别建立索引,那么作用会更大。另外,UNION ALL 要比 UNION 快很多(如果知道不重复,就应该使用Union All)

mysql> select * from students where first_name like  'Ade%'  or last_name like 'Ade%' ;

=>

mysql> select  from students where first_name like  'Ade%'  union all select  from students where last_name like  'Ade%' ;

 


3. 避免在开头使用通配符(Avoid Like Expressions With Leading Wildcards)
   会导致索引无法使用(比如 like '%abc')而进行全表扫描,索引就类似字典的目录,试想如果只知道词语的后半部分,又如何去查找目录呢?

   解决方法:
   1)对于'%xx',使用reverse函数:reverse(name) like reverse(‘%245′) 

   2)对于'%xx%',使用instr函数: instr(t.column,’xx’)> 0 

 


4. 使用Mysql的全文搜索(FTS:full-text search)

    使用举例:

mysql>Alter table students ADD FULLTEXT (first_name, last_name);
mysql>Select * from students where match(first_name, last_name) AGAINST ('Ade');  // 默认使用自然语言匹配单词

  关于FTS,有几个需要注意的地方:

  1)只在MyISAM或者InnoDB适用

  2)只用于字段char,varchar,text

  3)自5.7.6开始,支持CJK语言(需要使用ngram解析:ADD FULLTEXT INDEX `first_name` (`first_name` ASC, `last_name` ASC)  WITH PARSER ngram;)

  4)对于大量数据迁移,可以先迁移数据再创建FTS,这样比先建FTS再迁移快得多

 


5. 优化表结构

   1)数据类型:shorter is always better. 比如如果用户量不多于100,可以用TINYINT作为ID;再如如果DateTime够用,就不要用Timestamp;数字类型不要用varchar表示
      “shorter is alwasys better”同样适用于查询语句:保持查询简单且只返回必需的数据,减小通信间数据包的大小和数量是一个非常好的习惯,这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。

   2)避免使用Null:如果使用,则在sum这列值的时候就需要筛选,否则就会出现错误

   3)避免定义的列数太多,可以用多个小表代替一个大表,但也要注意不要过度设计

   4)join时尽可能少关联表

 


6. 使用Mysql的缓存机制

   查看是否使用缓存:show variables like 'have_query_cache';

   关于缓存的参数可以在my.cnf中设置

   对于缓存的命中,需要了解以下情况

   1)两个查询在任何字符上的不同(例如:空格、注释),都会导致缓存不会命中。

   2)如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表,其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间,返回不同的查询结果,将这样的查询结果缓存起来没有任何的意义

   3)缓存失效时机:查询对应的表数据发生变化

   4)只有当缓存带来的资源节约大于其本身消耗的资源时,才会给系统带来性能提升

   5)可以使用SQL_CACHE和SQL_NO_CACHE控制查询语句是否使用缓存,比如:select SQL_NO_CACHE count(*) from users where email = 'hello';

   6)不要轻易打开查询缓存,特别是写密集型应用。如果你实在是忍不住,可以将query_cache_type设置为DEMAND,这时只有加入SQL_CACHE的查询才会走缓存,其他查询则不会,这样可以非常自由地控制哪些查询需要被缓存

 

7. 用 PreparedStatement, 一般来说比 Statement 性能高

    一个 sql发给服务器去执行,涉及步骤:语法检查、语义分析, 编译,缓存

    详情可查看笔者的另一篇文章:PreparedStatement是如何防止SQL注入的?

 

 

 

参考:https://dzone.com/articles/how-to-optimize-mysql-queries-for-speed-and-perfor

云栖:https://yq.aliyun.com/articles/697956?spm=a2c4e.11163080.searchblog.38.270f2ec1kLwArF

树结构:https://www.cnblogs.com/tiancai/p/9024351.html

重复索引:https://www.cnblogs.com/happyflyingpig/p/7663000.html

全文搜索:https://dev.mysql.com/doc/refman/5.7/en/fulltext-search.html

 

持续补充中...

posted @ 2019-06-09 20:59  栖息之鹰  阅读(672)  评论(0编辑  收藏  举报