看到知乎上不少类似的问题,一个页面请求200个SQL是否合理,或者一个网站多少pv,总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 多条请求可以在程序中合并,对数据库操作只进行一次。
这样更新请求频次就极大下降了。

如果线上有实时性要求,线上可以保持一个内存数据做同步更新。
方法其实很简单,但是很有效

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