项目的 iBatis2 中有这样一条查询语句：

 

<select id="getRawFileList" parameterClass="java.util.HashMap" resultClass="com.defonds.mysql.raw.entity.TimelineRaw">
SELECT * FROM timeline_raw_
WHERE uid=#uid#
AND did=#did#
AND channelId=#channelId#
<isNotNull  property="sectionId"> AND sectionId = #sectionId#</isNotNull>
AND
(
(startTime BETWEEN #startTime# and #endTime#)
OR
(endTime BETWEEN #startTime# and #endTime#)
OR
(
<![CDATA[
startTime<=#startTime#
]]>
AND
<![CDATA[
endTime>=#endTime#
]]>
)
)
ORDER BY startTime;
</select>

　　根据实际业务向 timeline_raw 表注入一千万条数据，进行模拟测试(参考《sql 性能测试例子》)，发现 getRawFileList 的执行平均时间为 160 ms 以上。这是不能接受的。
　　考虑到实际业务中对于主键 rawId 查询条件甚少，我们把rawId主键索引取消掉，改为约束，却把sectionId+startTime+endTime作为主键(业务上能够保证其性，根据InnoDB索引规则，这个索引将成为我们新表的聚集索引)。然后把sectionId、startTime两个索引也取消掉，仅保留`uid`，`did`索引。
　　这样子，我们新表的索引实际上只有两个了：一个聚集索引(sectionId+startTime+endTime)一个非聚集索引(`uid`，`did`)。
　　再次进行模拟测试，同样的数据、数据量，同样的查询结果集，getRawFileList 执行平均时间已经降到了 11 ms。结果是令人振奋的，不是么？
　　使用 /dev/shm 来存储缓存的磁盘文件
　　在网站运维中，利用好了这一点，往往有意想不到的收获。以 tomcat 为例，可以通过修改 catalina.sh 中的 CATALINA_TMPDIR 值的路径来将缓存设置为 /dev/shm。
　　以 OSC 为例，他们是纯 Java 写的，部署在 tomcat 下。在长时间的在线运行之后，管理员发现网站响应速度奇慢，服务器负载正常，又找不出是哪里的问题。后来 df 一下，发现 tomcat 临时目录下的文件足足有 8G 之多，原来是 CPU 等待磁盘操作造成响应速度加长。于是他们将临时目录映射到 /dev/shm，网站响应速度从此奇快。
　　分析系统中每一个 SQL 的执行效率
　　以 MySql 为例，对于每个 SQL 好都 explain 一下。对于有明显效率问题的，通过 sql 优化、调索引等方法进行改进。
　　健康慢查询日志，检查所有执行超过 100 毫秒的 SQL
　　对于上线了的项目，健康慢查询日志，检查所有执行超过 100 毫秒的 SQL，看看有没有优化余地。对于没有上线的项目，可以进行场景模拟对嫌疑 SQL，或者对频繁使用的 SQL 进行性能测试，统计它们执行时间，得出平均值，画出曲线分析图，对于单表千万数据，执行时间超过 50ms 的 SQL 要重点关注。参考《sql 性能测试例子》。