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

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