qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

看曹政如何减少SQL请求

 首先为了防止某些专业挑刺人士无限制发挥,先声明几个前提

  1:索引优化是基础工作,没做好这个其他的不用提,但本文不展开此内容。

  2:优化数据库查询有非常多的分支,减少SQL请求只是其中一个领域,其他分支本文不涉及。

  3:在部分场景下,甚至需要增加SQL以解决诸如分布式或其他问题,本文不涉及。

  4:运维优化和其他优化手段本文不涉及。

  5:产品业务逻辑优化本文不涉及。

  6:其他本文没提到的内容欢迎自行联想,技术水准高超者请忽略本文。

  第一、查询请求的分析和裁剪

  线上系统,出现请求较多,数据压力较大(索引优化到位的前提下),我会让程序员输出一段时间的查询请求。(通常数据库操作有封装对象,直接记录日志即可,建议写入/dev/shm 以减少i/o压力,如果请求频次实在很高,可以取一定比例写入日志),然后基于日志分析。

  1、完全一致的查询请求有多少,平均每秒会出现多少这样的查询。

  比如常见的,所有页面都加载系统信息 select * from systeminfo;

  2、基于同一数据表同一主键的查询有多少,平均每秒会出现多少这样的查询

  比如 select name from userinfo where uid=10134;  select email from userinfo where uid=10134;

  这两种请求,是可以通过建立缓存机制来优化的,

  而且做了这个分析,会有一个很好的数据认知

  当前数据库每秒处理多少查询请求,其中可优化的冗余请求有多少,如果建立缓存可以减少多少请求。提升系统支撑性多少?

  对于一些不是特别出色的开源系统,分析一下会发现,可裁剪的查询请求是非常巨大的。

  第二、更新请求的分析和裁剪

  更新请求也可以优化,

  我们一般用mysql的情况下,是先解开binlog文件,还原为文本文件,然后分析

  基于同一数据表,同一主键的更新请求有多少,平均每个时间段出现多少这样的请求

  举例1:

  update user set lastacttime=.... where uid=10314; 经常更新最后活跃时间

  举例2:

  update posts set views=views+1 where pid=10004211; 更新同一个帖子显示数字

  如果这样的请求较多,那么可以有针对性的建立队列,定时异步更新。

  在异步更新过程中

  范例1 多条请求只要记住同一主键最后一条即可;

  范例2 多条请求可以在程序中合并,对数据库操作只进行一次。

  这样更新请求频次就极大下降了。

  如果线上有实时性要求,线上可以保持一个内存数据做同步更新。

  方法其实很简单,但是很有效

  简单总结

  第一,要随时了解自己的读写请求频次情况

  第二,一定时间范围内针对同数据表,同主键的读写请求,均是可优化,可裁剪的,但是也要考虑当时的系统负载构成和请求频次、影响度,抓大放小,解决主要问题即可。

  就这样,其他方面,参见前提说明。

posted on 2013-06-17 10:05 顺其自然EVO 阅读(309) 评论(0)  编辑  收藏 所属分类: 数据库DB2


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜