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

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 多条请求可以在程序中合并，对数据库操作只进行一次。

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

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

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

简单总结

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

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

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

原文链接：http://hi.baidu.com/ncaoz/item/600fd0daecef622939f6f7ca