欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

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

程序员文章站 2022-06-09 14:18:55
...
在一个运行超过半年的测试结果分析程序中,经理提出了一个新的要求,需要得到每一次单元测试运行的结果趋势图,以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语句即可完成历史数据更新。