看到知乎上不少类似的问题，一个页面请求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 多条请求可以在程序中合并，对数据库操作只进行一次。
这样更新请求频次就极大下降了。
如果线上有实时性要求，线上可以保持一个内存数据做同步更新。
方法其实很简单，但是很有效
简单总结
第一，要随时了解自己的读写请求频次情况
第二，一定时间范围内针对同数据表，同主键的读写请求，均是可优化，可裁剪的，但是也要考虑当时的系统负载构成和请求频次、影响度，抓大放小，解决主要问题即可。