1.1 業務場景：幾千萬數據量的工單表如何快速優化

這次項目優化的是一個郵件客服系統。它是一個SaaS（通過網絡提供軟件服務）系統，但是大客戶只有兩三家，最主要的客戶是一家大型媒體集團。

這個系統的主要功能是這樣的：它會對接客戶的郵件服務器，自動收取發到幾個特定客服郵箱的郵件，每收到一封客服郵件，就自動生成一個工單。之后系統就會根據一些規則將工單分派給不同的客服專員處理。

這個系統是支持多租戶的，每個租戶使用自己的數據庫（MySQL）。

這家媒體集團客戶兩年多產生了近2000萬的工單，工單的操作記錄近1億。

平時客服在工單頁面操作時，打開或者刷新工單列表需要10秒鐘左右。

該客戶當時做了一個業務上的變更，增加了幾個客服郵箱，然后把原來不進入郵件客服系統的一些客戶郵件的接收人改為這幾個新增加的客服郵箱，并接入這個系統。

發生這個業務變更以后，工單數量急劇增長，工單列表打開的速度越來越慢，后來客服的負責人發了封郵件，言辭急切，要求盡快改善性能。

項目組收到郵件后，詳細分析了一下當時的數據狀況，情況如下。

1）工單表已經達到3000萬條數據。

2）工單表的處理記錄表達到1.5億條數據。

3）工單表每日以10萬的數據量在增長。

當時系統性能已經嚴重影響了客服的處理效率，需要放在第一優先級解決，客戶給的期限是1周。

在客戶提出需求之前，項目組已經通過優化表結構、業務代碼、索引、SQL語句等辦法來提高系統響應速度，系統最終支撐起了3000萬數據的表查詢。這次只能嘗試其他方案。

因為給的時間太少了，所以也不太可能去做一些大的架構變動，項目組的預期是先用改動最小的臨時性方案讓客服可以正常工作。

如果不想改動架構，那么最簡單的方法就是使用數據庫分區，這樣的話甚至都不需要改代碼。

項目組一開始考慮用數據庫的分區功能，但是后來放棄了，下面說說為什么。