系统性能优化（一）

系统中用户访问日志的数据量，随着时间的推移，这张表的数据量会越来越大，因此我们需要根据业务需求，来对 日志查询模块的性能进行优化。

1） 分页查询优化 由于在进行日志查询时，是进行分页查询，那也就意味着，在查看时，至少需要查询两次： A. 查询符合条件的总记录数。--> count 操作 B. 查询符合条件的列表数据。--> 分页查询 limit 操作 通常来说，count() 都需要扫描大量的行（意味着需要访问大量的数据）才能获得精确的结果，因此是很难对该 SQL进行优化操作的。如果需要对count进行优化，可以采用另外一种思路，可以增加汇总表，或者redis缓存来专 门记录该表对应的记录数，这样的话，就可以很轻松的实现汇总数据的查询，而且效率很高，但是这种统计并不能 保证百分之百的准确 。对于数据库的操作，“快速、精确、实现简单”，三者永远只能满足其二，必须舍掉其中一 个。

2） 条件查询优化 针对于条件查询,需要对查询条件,及排序字段建立索引。

3） 读写分离 通过主从复制集群，来完成读写分离，使写操作走主节点， 而读操作，走从节点。 4） MySQL服务器优化

5） 应用优化

1.性能优化 - 分页

优化count

创建一张表用来记录日志表的总数据量：

create table log_counter(
logcount bigint not null
)engine = innodb default CHARSET = utf8;

在每次插入数据之后，更新该表 ：

<update id="updateLogCounter" >
update log_counter set logcount = logcount + 1
</update>

在进行分页查询时, 获取总记录数，从该表中查询既可。

<select id="countLogFromCounter" resultType="long">
select logcount from log_counter limit 1
</select>

优化 limit

在进行分页时，一般通过创建覆盖索引，能够比较好的提高性能。一个非常常见，而又非常头疼的分页场景就是 "limit 1000000,10" ，此时MySQL需要搜索出前1000010 条记录后，仅仅需要返回第 1000001 到 1000010 条记 录，前1000000 记录会被抛弃，查询代价非常大。

当点击比较靠后的页码时，就会出现这个问题，查询效率非常慢。

优化SQL：

select * from operation_log limit 3000000 , 10;

将上述SQL优化为 :

select * from operation_log t , (select id from operation_log order by id limit
3000000,10) b where t.id = b.id ;

<select id="selectListByCondition" parameterType="map" resultType="operationLog">
select
id ,
operate_class as operateClass ,
operate_method as operateMethod,
return_class as returnClass,
operate_user as operateUser,
operate_time as operateTime,
param_and_value as paramAndValue,
cost_time as costTime,
return_value as returnValue
from operation_log t,
(select id from operation_log
<where>
<include refid="oplog_where"/>
</where>
order by id limit #{start},#{rows}) b where t.id = b.id
</select>

 优化前后的sql 性能比较