我的一个月结统计报表已经优化,性能提升了10~15倍,原先计算1天需要10~15秒,现在只需1秒。计算一个月的数据原先超过180秒,服务器超时,现在也在15~20秒以内完成。
优化思想是多表join的时候,先对数据进行筛选,用尽可能少的数据 join。
例如:
表join之前先用where过滤数据(性能高):
(select * from gr_sp_order o where o.createat>111111 and o.createat<222222 ) t inner join ( SELECT * from gr_sp_grouppay where orderNum>=333333 and orderNum<=444444 ) p on t.orderNum=p.orderNum)
表先join 后用where过滤 (性能低):
select * from gr_sp_order o inner join gr_sp_grouppay p on o.orderNum=p.orderNum where o.createat>111111 and o.createat<222222 and p.orderNum>=333333 and p.orderNum<=444444
以上两种表关联查询在数据量少是几乎没有差别,只有在数据量大时,性能差异才能体现出来,店管家刚上线那会性能还好,现在越来越慢的原因也就在此。
我以前使用微软的sqlserver数据库,没有这样的性能差异,现在使用mysql发现存在这个问题,说明各种数据库也存在差异。
优化思想是多表join的时候,先对数据进行筛选,用尽可能少的数据 join。
例如:
表join之前先用where过滤数据(性能高):
(select * from gr_sp_order o where o.createat>111111 and o.createat<222222 ) t inner join ( SELECT * from gr_sp_grouppay where orderNum>=333333 and orderNum<=444444 ) p on t.orderNum=p.orderNum)
表先join 后用where过滤 (性能低):
select * from gr_sp_order o inner join gr_sp_grouppay p on o.orderNum=p.orderNum where o.createat>111111 and o.createat<222222 and p.orderNum>=333333 and p.orderNum<=444444
以上两种表关联查询在数据量少是几乎没有差别,只有在数据量大时,性能差异才能体现出来,店管家刚上线那会性能还好,现在越来越慢的原因也就在此。
我以前使用微软的sqlserver数据库,没有这样的性能差异,现在使用mysql发现存在这个问题,说明各种数据库也存在差异。