当前位置:Gxlcms > mysql > MySQL性能调优:一个真实案例的解析_MySQL

MySQL性能调优:一个真实案例的解析_MySQL

时间:2021-07-01 10:21:17 帮助过:85人阅读

在一个运行超过半年的测试结果分析程序中,经理提出了一个新的要求,需要得到每一次单元测试运行的结果趋势图,以framework为类别显示是成功还是失败。

当时的数据库中其中一个大表已经还有超过600万行记录,可以预计在接下来的时间中,会以类似的速度增长。同时由于数据会做定期清理,所以在初始的设计中没有做分区表的设计。

该数据库系统是一个OLAP系统,是一个一次写入,多次读取的系统,表间的关系呈现星型结构。下面是具体的表结构设计:

CREATE TABLE kitchen_revisions(id int auto_increment not null primary key, number varchar(24));CREATE TABLE kitchen_driver_types(id int auto_increment not null primary key, name varchar(24));CREATE TABLE kitchen_test_types(id int auto_increment not null primary key, name varchar(24));CREATE TABLE kitchen_trigger_bies(id int auto_increment not null primary key, name varchar(64));CREATE TABLE kitchen_test_frameworks(id int auto_increment not null primary key, name varchar(50));CREATE TABLE kitchen_test_suites(id int auto_increment not null primary key, framework_id int, name varchar(100), CONSTRAINT FOREIGN KEY(framework_id) REFERENCES test_frameworks(id));CREATE TABLE kitchen_test_cases(id int auto_increment not null primary key, suite_id int, name varchar(100), CONSTRAINT FOREIGN KEY(suite_id) REFERENCES test_suites(id));CREATE TABLE kitchen_test_results(id int auto_increment not null primary key, revision_id int, driver_id int, case_id int, type_id int, trigger_id int, result varchar(100), CONSTRAINT FOREIGN KEY(revision_id) REFERENCES revisions(id), CONSTRAINT FOREIGN KEY(driver_id) REFERENCES driver_types(id), CONSTRAINT FOREIGN KEY(case_id) REFERENCES test_cases(id), CONSTRAINT FOREIGN KEY(type_id) REFERENCES test_types(id), CONSTRAINT FOREIGN KEY(trigger_id) REFERENCES trigger_bies(id));ALTER TABLE kitchen_test_suites ADD INDEX IDX_SUITES(framework_id);ALTER TABLE kitchen_test_cases ADD INDEX IDX_CASES(suite_id);ALTER TABLE kitchen_test_results ADD UNIQUE INDEX IDX_RESULTS(trigger_id, type_id, , case_id, driver_id, revision_id);ALTER TABLE kitchen_test_results ADD UNIQUE INDEX IDX_KITCHEN(revision_id, case_id);ALTER TABLE kitchen_test_results ADD UNIQUE INDEX IDX_KITCHEN2(case_id, revision_id);ALTER TABLE kitchen_test_results ADD INDEX IDX_REGRESSION(regression);ALTER TABLE revisions ADD UNIQUE(number);ALTER TABLE test_frameworks ADD UNIQUE(name);ALTER TABLE driver_types ADD UNIQUE(name);alter table test_cases add column golden float(8,2);alter table test_results add column regression bool, add column goldendelta float(8,2), add column previousdelta float(8,2);


kitchen_test_results 就是那个核心的大表。

要得到每次run的各种条件下的运行结果,都需要按kitchen_revisions表结合kitchen_driver_types,kitchen_test_types,kitchen_trigger_bies等基础数据表的关联,以及对kitchen_test_frameworks, kitchen_test_suites,kitchen_test_cases结合大表kitchen_test_results来查询得到。但是如果每次对查询出来的结果集依次比较得到每一个test case的结果,是相当耗时的,即使是实现了类似Oracle分析函数的查询语句。

通过对现有的kitchen_test_frameworks,kitchen_test_suites和kitchen_test_cases表的分析,可以得出一个基本的概念,就是归属于某一特定的test_suites的test_cases数量最多不会超过某个数,那就可以根据这一事实,用一个巧妙的方法来解决这个问题。

因为每一个test_case的结果只会有三种可能,pass,fail和skip。那就可以在Kitchen_test_results表中,添加一个整型字段,并设定三个对应的整数来表示三种结果。这个额外字段的值可以在插入记录求得。如何设定三个整数,具有一定的技巧,比如说在所有suite中,其中含有最多的的test case的那个suites,包含的test cases的个数为100个,那么我们再根据用一定的冗余度,可以设定pass的整数为0,skip的整数为1,fail的整数为300。

在这个辅助字段的帮助下,我们就可以在上面那个多表连接的查询中,运用sum,group by, order by,以一个sql函数求取出所有run中的test_framework的结果,判断的依据就是sum如果等于0,则pass,如果小于300,则有caseskip,如果大于300则表是fail。

通过这一设计,就避免了原先SQL中的显示的性能问题。


后续的一个需求,是要获取每一个run中,testcase的数量,pass,skip和fail的个数。

同样的考虑,因为这是一个一次插入,多次读取的系统,插入的效率不是系统的最高优先级,读取的效率才是最高的。因此,在这个问题的解决上,可以引用一贯的思路,空间换时间。相对于上一个问题的解决思路不同(表中加字段),这次是添加一个summary表。在这个表中,记录每一run的所有统计信息。这些值,可以在每一次结果插入完成后,通过对现有表的一个简单查询即可获取,然后转存到summary表中。相对之前,插入时多做了几个查询和插入动作。但是后续的统计信息的查询确是飞快的。


上述两个解决方案中,都会涉及到历史记录的表的更新,这同样不是特别困难的事。仔细设计两个update和select insert语句即可完成历史数据更新。

人气教程排行