mysql优化之路

下面总结了一些工作常见的sql优化例子,虽然比较简单,但很实用,希望对大家有所帮助。sql优化一般分为两类,一类是sql本身的优化,如何走到合适的索引,如何减少排序,减少逻辑读;另一类是sql本身没有优化余地,需要结合业务场景进行优化。即在满足业务需求的情况下对sql进行改造,已提高sql执行速度,减少响应时间。

例子1:

SELECT ID FROM SENDLOG WHERE TO_DAYS(NOW())-TO_DAYS(GMT_CREATE) > 7;

问题:对索引列GMT_CREATE进行了运算,无法使用索引

优化后sql:

select id from sendlog where gmt_create < now() - 7

例子2:

SELECT * FROM SENDLOG where result = 1 and gmt_create > ‘2013-10-29 12:40:44‘ limit 2000;

问题:result列含有索引,但mysql执行计划没有用到。

分析:result类型为char,传递的值1为整型,数据类型不一致,导致没法用索引,对于时间类型gmt_create > ‘2013-10-29 12:40:44‘,可以直接使用。

优化后sql:

SELECT * FROM SENDLOG where result = ‘1‘ and gmt_create > ‘2013-10-29 12:40:44‘ limit 2000;

例子3:

场景:获取某个卖家未读的消息。

select count(*) from mc_msg where receiver=‘sun098‘ and status=‘UNREAD‘ and title is not null;

问题:有时候db负载飙高,sql响应时间变慢。

分析:导致db负载飙高的原因是多个大卖家并发查询的时,cpu和逻辑读增加,load飙高。由于receiver,status已有索引,sql本身已经没有优化空间,了解业务后发现其实业务不需要精确值,如果大于99条,页面就直接显示为99+

优化后sql:

select count(*) from (select id from mc_msg where receiver=‘sun098‘ and status=‘UNREAD‘ and title is not null limit 100) a;

例子4:

场景:查看历史订单留言记录,未读留言的放在前面,已读的放在后面,并且按时间递减排序

select * from(

select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ

from message_relation_sender

WHERE SENDER_ALI_ID = 119545671  and UNREAD_COUNT > 0

order by LAST_MESSAGE_ID desc) m

union all

select * from(

select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender

WHERE SENDER_ALI_ID = 119545671  and UNREAD_COUNT = 0

order by LAST_MESSAGE_ID desc) n limit 5000,15;

分析:

(1)unread_count表示未读的订单留言记录数目;

(2)第一个子查询获取未读留言记录,第二子查询获取已读留言记录;

(3)LAST_MESSAGE_ID 递增,最新的订单留言,LAST_MESSAGE_ID最大。

(4)limit 5000,15是分页查询

这里使用union all,主要特点在于union all 不对结果集排序,直接合并,达到了“未读留言的放在前面,已读的放在后面”的效果,但同时也造成了两次扫描索引的结果,每个子查询都需要排序;而且union all还会产生临时表,执行代价会更大。

优化:

这里看到unread_count实际值对这个查询没有实际意义,我们只需要区分已读和未读即可。由于sql本身已经没有优化余地,考虑对表结构进行修改,加一个字段is_read,表示已读和未读。is_read=2表示未读;is_read=1表示已读。通过组合索引(SENDER_ALI_ID,is_read, LAST_MESSAGE_ID),既可以完成过滤,还可以完成排序。

优化后sql:

select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender

where SENDER_ALI_ID = 119545671  order by is_read desc, LAST_MESSAGE_ID desc limit 5000,15

第二次优化:

由于索引不包含所有的返回字段,因此需要回表,而mysql对于limit 5000,15的查询却需要返回5015次,这种无效的返回很影响查询效率。

分页的优化写法:

select t1.ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender t1,

(select id

from message_relation_sender

where SENDER_ALI_ID = 119545671 order by is_read desc, LAST_MESSAGE_ID desc limit 5000,15

)t2 where t1.id = t2.id

分析:由于id是主键,不需要回表,通过连接查询,最终只需要15次回表即可。

时间: 2024-10-23 01:26:02

mysql优化之路的相关文章

[转载] 单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构

原文: http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=209406532&idx=1&sn=2e9b0cc02bdd4a02f7fd81fb2a7d78e3&scene=1&key=0acd51d81cb052bce4ec2a825666e97fe7d6e1072fb7d813361771645e9403309eb1af025691162c663b60ea990c3781&ascene=0&

【转】单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构

此文是根据杨尚刚在[QCON高可用架构群]中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计.前新浪高级数据库工程师,负责新浪微博核心数据库架构改造优化,以及数据库相关的服务器存储选型设计. 前言 MySQL数据库大家应该都很熟悉,而且随着前几年的阿里的去IOE,MySQL逐渐引起更多人的重视. MySQL历史 1979年,Monty Widenius写了最初的版本,

mysql优化案例

MySQL优化案例 Mysql5.1大表分区效率测试 Mysql5.1大表分区效率测试MySQL | add at 2009-03-27 12:29:31 by PConline | view:60, comment:0 mysql5.1开始支持数据表分区了,原来的分表可以不用了,分表的不足在于多表查询不方便.呵呵,下面来简单测试下表分区的查询效率. 1.用来测试的数据为discuz论坛的数据库,表为cdb_posts表,数据量为1500多万条mysql> select count(*) fro

php+Mysql 优化,百万至千万级快速分页

php+Mysql 优化,百万至千万级快速分页 MySql 性能到底能有多高?用了php半年多,真正如此深入的去思考这个问题还是从前天开始.有过痛苦有过绝望,到现在充满信心!MySql 这个数据库绝对是适合dba级的高手去玩的,一般做一点1万篇新闻的小型系统怎么写都可以,用xx框架可以实现快速开发.可是数据量到了10万,百万至千万,他的性能还能那么高吗?一点小小的失误,可能造成整个系统的改写,甚至更本系统无法正常运行!好了,不那么多废话了.用事实说话,看例子: 数据表 collect ( id,

6.MySQL优化---高级进阶之表的设计及优化

转自互联网整理. 优化之路高级进阶--表的设计及优化 优化①:创建规范化表,消除数据冗余 数据库范式是确保数据库结构合理,满足各种查询需要.避免数据库操作异常的数据库设计方式.满足范式要求的表,称为规范化表,范式产生于20世纪70年代初,一般表设计满足前三范式就可以,在这里简单介绍一下前三范式. 通俗的给大家解释一下(可能不是最科学.最准确的理解) 第一范式:属性(字段)的原子性约束,要求属性具有原子性,不可再分割: 第二范式:记录的惟一性约束,要求记录有惟一标识,每条记录需要有一个属性来做为实

Mysql优化(转)

Mysql优化主要通过执行计划,索引,sql语句,调整mysql内部配置 (http://blog.chinaunix.net/uid-11640640-id-3426908.html) 一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)  

MySQL优化—工欲善其事,必先利其器之EXPLAIN

转自:http://www.cnblogs.com/magialmoon/archive/2013/11/23/3439042.html mysql官方手册关于explain命名的说明文档:https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain_select_type 最近慢慢接触MySQL,了解如何优化它也迫在眉睫了,话说工欲善其事,必先利其器.最近我就打算了解下几个优化MySQL中经常用到的工具.今天就简单介绍下

MySQL优化概述

MySQL优化概述 设计: 存储引擎,字段类型,范式 功能: 索引,缓存,分区. 架构: 主从复制,读写分离,负载均衡. 合理SQL: 测试,经验. 存储引擎 Create table tableName () engine=myisam|innodb; 一种用来存储MySQL中对象(记录和索引)的一种特定的结构(文件结构) 存储引擎,处于MySQL服务器的最底层,直接存储数据.导致上层的操作,依赖于存储引擎的选择. Tip:存储引擎就是特定的数据存储格式(方案) Show engines 查看

小菜鸟mysql优化解决方案

根据小菜鸟的个人习惯,自己的编写的一套MYSQL优化方案,感觉还是有点儿菜,望大家谅解,不足之处,请大神们互动! #mysql优化解决方案 #公共参数默认值: max_connections = 151 #同事处理多大连接数,推荐设置最大连接数是上限连接数的80%左右 sort_buffer_size = 2M #查询排序时缓冲区大小,只对order by和group by起作用,可增大此值为16M open_files_limit = 1024 #打开文件数限制,如果show global s