总结一下近来要做的优化工作

本文探讨了MySQL中分页查询与Count统计优化的方法,包括如何改进LIMIT分页提高效率,以及解决InnoDB表Count统计瓶颈的问题。

文章持续更新,很多经验也是在网络搜寻,请大家明白。

 

公司的网站 负载越来越高,MYSQL 的负担也重了。这几天都在处理数据库 ,争取能减少数据 库的负载,因为大多数的瓶颈都是数据库引起的。

今天先总结一下:LIMIT

当初我做分页是这样写sql的


page       表示页码
pagesize  表示每页的显示数量
conditon  表示一些条件

 

这样分页在早期没有出现什么问题,但当表里的数据达到了100W,慢慢就出现问题了,搜索 几百页的时候,经常要用到2秒多 上网搜索了一下,网上的改法可以参考一下,暂时解决 问题

 

 

 

sql_no_cache 表示不缓存 。这样一改0.0几秒就可以搞掂了,其实这样改主要是因为用到了索引id。

为什么上面那句没有用到索引?这问题让同学们思考一下

我先讲一下我的condition是 :

 
 audit=1 AND share=1

我表的索引设计是,主键是id,audit和share是联合索引

迟一点总结一下innodb表的count优化

 

------------------------------------------------------

MYSQL里的myisam表有内置的计数器,所以用count是很快,但是innodb就不一样了,每次count都全表扫描一次

SELECT SQL_NO_CACHECOUNT( * ) FROM `cdb_game_area`WHERE gameid =1063 AND STATUS IN ( 0, -1) ;

 

表里有大约200W数据,这样一搜索需要时间 是0.39秒,忙时可能去到2秒,这个表的索引是 gameid,STATUS,但没有效果,建了索引感觉用不上. 如果将语句 改成

SELECT SQL_NO_CACHECOUNT( * ) FROM `cdb_game_area`WHERE gameid =1063;

就是去除后面那个条件,统计的结果更多了,但速度更快了,提高了10几陪.什么原因呢?
上网查了一下

但我第一条 sql语句都是用了第二索引,只不过多了个in条件,为什么速度这么慢呢?很明显关键就是这个in,在这个情况下它带来了很大的负面影响,目前我的处理办 法是不要in,因为我这个统计多一点数据没有影响,也是用来分页的,没有很多人翻到几万页去的.不知遇到这种情况大家有什么好方法建议?


迟点总结一下 什么情况下"强制使用索引",希望大家多多关注,一起讨论

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值