本文讲的第一个场景是冷热分离。简单来说，就是将常用的“热”数据和不常使用的“冷”数据分开存储。
本章要考虑的重点是锁的机制、批量处理以及失败重试的数据一致性问题。这部分内容在实际开发中的“陷阱”还是不少的。
首先介绍一下业务场景。
这次项目优化的是一个邮件客服系统。它是一个SaaS（通过网络提供软件服务）系统，但是大客户只有两三家，最主要的客户是一家大型媒体集团。
这个系统的主要功能是这样的：它会对接客户的邮件服务器，自动收取发到几个特定客服邮箱的邮件，每收到一封客服邮件，就自动生成一个工单。之后系统就会根据一些规则将工单分派给不同的客服专员处理。
这个系统是支持多租户的，每个租户使用自己的数据库（MySQL）。
这家媒体集团客户两年多产生了近2000万的工单，工单的操作记录近1亿。
平时客服在工单页面操作时，打开或者刷新工单列表需要10秒钟左右。
该客户当时做了一个业务上的变更，增加了几个客服邮箱，然后把原来不进入邮件客服系统的一些客户邮件的接收人改为这几个新增加的客服邮箱，并接入这个系统。
发生这个业务变更以后，工单数量急剧增长，工单列表打开的速度越来越慢，后来客服的负责人发了封邮件，言辞急切，要求尽快改善性能。
项目组收到邮件后，详细分析了一下当时的数据状况，情况如下。
1）工单表已经达到3000万条数据。
2）工单表的处理记录表达到1.5亿条数据。
3）工单表每日以10万的数据量在增长。
当时系统性能已经严重影响了客服的处理效率，需要