1.1 业务场景：几千万数据量的工单表如何快速优化

这次项目优化的是一个邮件客服系统。它是一个SaaS（通过网络提供软件服务）系统，但是大客户只有两三家，最主要的客户是一家大型媒体集团。

这个系统的主要功能是这样的：它会对接客户的邮件服务器，自动收取发到几个特定客服邮箱的邮件，每收到一封客服邮件，就自动生成一个工单。之后系统就会根据一些规则将工单分派给不同的客服专员处理。

这个系统是支持多租户的，每个租户使用自己的数据库（MySQL）。

这家媒体集团客户两年多产生了近2000万的工单，工单的操作记录近1亿。

平时客服在工单页面操作时，打开或者刷新工单列表需要10秒钟左右。

该客户当时做了一个业务上的变更，增加了几个客服邮箱，然后把原来不进入邮件客服系统的一些客户邮件的接收人改为这几个新增加的客服邮箱，并接入这个系统。

发生这个业务变更以后，工单数量急剧增长，工单列表打开的速度越来越慢，后来客服的负责人发了封邮件，言辞急切，要求尽快改善性能。

项目组收到邮件后，详细分析了一下当时的数据状况，情况如下。

1）工单表已经达到3000万条数据。

2）工单表的处理记录表达到1.5亿条数据。

3）工单表每日以10万的数据量在增长。

当时系统性能已经严重影响了客服的处理效率，需要放在第一优先级解决，客户给的期限是1周。

在客户提出需求之前，项目组已经通过优化表结构、业务代码、索引、SQL语句等办法来提高系统响应速度，系统最终支撑起了3000万数据的表查询。这次只能尝试其他方案。

因为给的时间太少了，所以也不太可能去做一些大的架构变动，项目组的预期是先用改动最小的临时性方案让客服可以正常工作。

如果不想改动架构，那么最简单的方法就是使用数据库分区，这样的话甚至都不需要改代码。

项目组一开始考虑用数据库的分区功能，但是后来放弃了，下面说说为什么。