SQL1:(select customerd, customername, companyname, realcompanyname from tb_shifen_customerwhere urldomain like "%.cn" and status=3 and accountm>0 limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status in (1,4,6) and status=3 and accountm<=0 and invalidate>=date_sub(curdate(),interval ? day) limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status in (1,4,6) and accountm>0 limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status=2 limit 10);
SQL1 | 执行时间 | ||
Concurrency=1 | Concurrency=10 | Concurrency=100 | |
Icc编译的mysql | 36.01s | 31.20s | 162.78s |
Gcc编译的mysql | 41.02s | 40.30s | 181.83s |
Icc较gcc的提升 | 12.6% | 22.0% | 10.5% |
表8
SQL2:select count(*) from tb_customer where urldomain like "%.cn";
SQL2 | 执行时间 | ||
Concurrency=1 | Concurrency=10 | Concurrency=100 | |
Icc编译的mysql | 0.014s | 0.014s | 0.029s |
Gcc编译的mysql | 0.026s | 0.027s | 0.035s |
Icc较gcc的提升 | 41.2% | 48.1% | 17.1% |
表9
SQL3:select cust.cust_id,cust.cust_stat_1,cust.cust_stat_2,cust.cust_name, cust.cust_branch_name,cust.cust_input_type,cust.add_time,cust.cust_follow_num, cust.cust_trade_1,cust.cust_trade_2,dis.distribute_time from tb_customer cust left join tb_cust_distribute dis on cust.cust_id=dis.cust_id and dis.state=1 where cust.cust_id>0 and cust.cust_stat_1 in(8) and cust.pose_id=157 order by cust.cust_id desc limit 1170 , 15;
SQL2 | 执行时间 | ||
Concurrency=1 | Concurrency=10 | Concurrency=100 | |
Icc编译的mysql | 2.839s | 3.631s | 9.554s |
Gcc编译的mysql | 2.828s | 3.740s | 10.867s |
Icc较gcc的提升 | -0.3% | 2.91% | 12.1% |
表10
上述3个类型的SQL是从测试库上执行的读操作中挑选出来的,相应的表的引擎改成了MyISAM引擎。这3个SQL涉及了扫表,索引扫描,排序等操作。从测试的结果上看,icc编译的mysql对MyISAM引擎读操作的优化效果明显。从执行时间上看(QPS)减少大概在10%-20%之间(QPS增加10%-20%)。
SQL4:update tb_cust_app tc left join (select count(distinct f.cust_id) num, follow_id from tb_follow_assignf, tb_customer c where f.cust_id=c.cust_id and c.cust_stat_1<>5 group by follow_id) tf on tc.user_id = tf.follow_id set tc.ownered_size=ifnull(tf.num,0) ;
SQL2 | 执行时间 | ||
Concurrency=1 | Concurrency=10 | Concurrency=100 | |
Icc编译的mysql | 31.279s | 42.290s | 342.80s |
Gcc编译的mysql | 33.274s | 53.731s | 566.374s |
Icc较gcc的提升 | 6.0% | 21.23% | 39.5% |
表11
SQL4同上一节的SQL3。在上一节InnoDB引擎下,icc编译的mysql对于此SQL在执行时间上明显慢于gcc编译的mysql,也主要是因为该SQL导致innodb全脚本测试icc编译的mysql慢于gcc编译的mysql。但是对于MyISAM引擎,从测试结果上看,icc编译的mysql明显优于gcc编译的mysql。从测试可以看出icc编译的mysql对MyISAM写操作也有优化效果,从执行时间上看(QPS)减少大概在10%-20%之间(QPS增加10%-20%)。
5 测试结论
从两个维度上总结测试结论:1存储引擎维度;2CPU,IO负载。
从存储引擎维度:对于MyISAM引擎,从sql-bench,mysqlslap使用某数据库数据测试结果上看,icc编译的mysql无论从读操作还是写操作都有优化效果,SQL执行时间平均减少10%-20%。对于一些比较消耗CPU的SQL(比如排序等,执行时间较长的SQL),在一定的并发下优化效果更明显。
对于InnoDB引擎,从sql-bench,mysqlslap使用全脚本测试结果上看,icc编译的mysql较gcc编译的mysql从QPS(SQL执行时间)没有优势,甚至是劣势。同时从sql-bench,全脚本中的逐个SQL分析来看:对于利用primary key或者全表扫描的SQL,icc编译的mysql有一些优化效果;对于利用辅助索引的SQL,icc编译的mysql在执行时间上比gcc编译的mysql慢。分析原因,InnoDB使用聚簇索引存储数据,利用辅助索引时,还需要走一遍primary key,这中间会有比较多的随机读等操作。
从IO,CPU负载维度:通过测试中对于资源的统计和对比,icc编译的mysql在用户态cpu开销上较gcc编译的mysql小(相差不大);在内核态cpu开销要比gcc编译的mysql多;在内存上开销上icc编译的mysql稍小。Icc对于CPU密集,IO负载不重的场景,优化效果明显;对于IO负载较重的场景,icc编译的mysql优化效果可能不明显。
综上所述:icc编译的mysql用于MyISAM引擎,较gcc编译的mysql优化效果明显。对于InnoDB引擎,使用辅助索引等操作,icc编译的mysql比gcc编译的mysql在执行时间上要慢,存在劣势。对于使用全表扫描、primary key的InnoDB操作,在低并发下,icc编译的mysql在执行时间上不会慢,在高并发下icc编译的mysql具有优势。同时业务类型是CPU密集型,而不是IO密集型,有助于发挥icc编译器的优化效果。
转载于:https://blog.51cto.com/baidutech/748545