我真的是上来讲一个笑话的,这是个传统笑话,需要慢慢讲。
我同事离职以后,统计平台的所有代码就被我接过来了。这个统计平台是用MySQL搭建的,5.1版本,服务器是DELL的,有16个CPU和32G内存,700G的data空间,说真的这个配置对于我这种喜欢IOE的人来说实在是看不下去。
接过这个系统后我发现有一个过程需要跑三个小时,从前4点开始跑,到早上9点前也就出来了,于是也就没有什么。可是后来因为生产服务器压力很大,ETL的 时间被推后了很多,导致我的过程只能7点开始跑,这样子,加上数据入库,这个系统的日报往往要11点甚至12点才能跑出来,领导问我为什么没有数据的时候 我真的不知道该如何狡辩。于是我想到了把计算过程迁移到Oracle上。我也这么做了,效果很好,这个三小时过程Oracle只需要不到1分钟然后 spool出来load data都比原来的过程快很多倍。于是我就安心的用起了Oracle。
但是我今天工程师精神泛滥了,我想知道为什么同样是数据库,人家阿里能把性能调校的那么好,我们就要等那么久?
我跟踪了一下,最慢的是这样的一个SQL:
select distinct b.name from table_a a inner join table_b b on a.id = b.id group by b.name
其中A表1亿余数据,B表2千万左右,数据量可以说已经很大了。a的ID有一个索引,explain了以后这个SQL也走了索引,两个表都走了。这就很奇 怪了,于是继续看执行计划,extra那里有个temp table还有一个filesort。于是我开始想笑,这是谁啊,distinct了还要group by一下b.name?于是我检视了一下b的表结构,这个表上的name是有一个索引的。我于是懂了从前的程序员为什么要画蛇添足的加一个group by。这在Oracle程序员看来是愚蠢的行为里,其实蕴含了一个MySQL的小技巧。我接触MySQL不长时间,但是通过读各种书籍发现MySQL的索 引很有趣,尤其是聚集索引,整个InnoDB表就是一个索引。
扯远了,这个SQL里,就是因为这个group by让b表也走了索引,但是,当时的程序员应该是忘掉了去掉前面的distinct,于是导致了悲剧的发生。
这个SQL完整版是这样子的:
insert into table_c(day_id, name, flag) select '20131128', distinct b.name, 1 from table_a a inner join table_b b on a.id = b.id group by '20131128', b.name;
去掉了distinct以后这个SQL还是很慢,半天插入不了。table_c有很多索引,这是个典型的DW表,很大。于是我建了一个中间表,只有一个字 段name,可是我发现插入的速度还是很慢,非常慢,于是我想起了几天前我看的《高性能MySQL》,里面169页还是179页讲过页分裂的概念,提及了 一个小技巧,就是每个表都应该有一个自增的主键,这样子插入速度会有一定的提升,于是我把mid表改了,有两个字段:id,name,其中id是自增的主 键。这样一来,插入mid表只需要5min左右,而把mid表用简单的select语句插入table_c只需要20s。是我想要的效率。
我学习MySQL只有短短的几个月时间,而且没有时间从最基础的开始学,都是需要什么知识就赶紧去看《高性能MySQL》,这本书真不错,当做一本救急用 的字典确实可以满足作为一个开发人员的需要。当然了,我的定位是开发型DBA,这本书里讲管理入门的还比较少,我还是要好好学习。欢迎大家指正。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28207565/viewspace-1061702/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28207565/viewspace-1061702/