非持久化统计信息
统计信息没有保存在磁盘上,而是频繁的实时计算统计信息;
每次对表的访问都会重新计算其统计信息;
假设针对一张大表的频繁查询,那么每次都要重新计算统计信息,很耗费资源。
持久化统计信息
把一张表在某一时刻的统计信息值保存在磁盘上;
避免每次查询时重新计算;
如果表更新不是很频繁,或者没有达到 MySQL 必须重新计算统计信息的临界值,可直接从磁盘上获取;
即使 MySQL 服务重启,也可以快速的获取统计信息值;
统计信息的持久化可以针对全局设置也可以针对单表设置。
接下来,详细说 MySQL 统计信息如何计算,何时计算,效果评估等问题。在 MySQL Server 层来控制是否自动计算统计信息的分布,并且来决策是持久化还是非持久化。
从语句本身来看,应该没有太多优化的余地了count(distinct a._url) CUrl 这里那个distinct完全可以不要。因为你的a._url在group by里面,已经完成了distinct功能了。你也知道distinct得支出的。
建议:
1) 用view, 譬如t_gw_merge_log a, t_gw_netuser u on a._uid=u._id 建立view,其他依次类推。我曾经作过9个表的连接(DB2),用了view之后,性能提升了30%。。 view只是把你的表里面只需要的字段拿出来从而减少表得扫描量。
语法:CREATE VIEW tab_view AS SELECT field1, file2 , filed3 FROM tab WHERE...
2) 因为sum(p._ul) SUl,sum(p._dl) SDl这两个聚合函数引起的,因为相对应的t_gw_applog 这个表数据也很多。如果是因为这个,就要建立适当的索引了。下午有时间再研究下。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)