本次总结主要包含两个部分内容一是关于生产环境删除海量数据的操作和注意事项，二是关于设计的粒度，成本，以及项目需求变化扩展的一些思考。
首先关于海量数据删除的背景是这样的：程序需要不断地解析平台推送的邮件，而因为平台的程序问题，导致推送了很多重复的邮件到数据库中，从而导致解析出了很多重复的邮件。经后台统计大概重复的量达到了100多万。
去重删除面临的问题：1.去重时要考虑有一部分邮件可能已经经过用户查阅使用，从而产生了关联数据，这部分邮件理论上不能删除。
2.虽然邮件重复的量只有100多万，但是因为邮件被解析的时候还会产生大量的关联数据，比如通过文本分析产生的要素信息，关系信息等，这些也要进行关联删除，而这些数据的数据量会是邮件的好几倍（因为一个邮件可以提取出多个要素信息）。
3.邮件以及其关联的数据表，数据量都很大（百万级别），不能够直接通过sql去关联查询删除。
问题的解决方案：
1.与客户沟通过后，其表示邮件方面的功能因为上线时间不长，并没有怎么使用，只有二十多条客户使用产生的数据，并且客户说均为测试用数据可以直接删除。
2、3其实是一个问题，即如何安全地批量删除海量数据。首先，要注意的是删除前涉及的表都要进行相应的备份工作。然后，面对海量数据的删除，因为用户的数据一般都是非常重要的，建议少量多次可控的删除，这里针对海量的邮件删除，可以根据邮件倒入的时间，先做统计分析后，根据重复邮件的时间分布，按时间段来进行删除，如果一个时间段的重复邮件太多，则可以将时间段划分得更细一些，从而使得，每次删除的数据是可以被控制的。对于关联的数据，则同样可以通过按时间分段的方式少量多次的删除。另外，删除操作，代码层面，只要确保删除关联信息的操作放置在前面，最后删除关联的主体，则可以不开启事务（可以获得更好的性能），因为即便只成功删除部分关联信息，后续重新检索重复主体的时候还是会检索到。
另一想说下的是，关于设计和需求变化的思考。在有几年的工作经验后，一方面会想这个需求做出来是什么样子，用户会怎么使用，是否可行，另一方面，在设计的时候也总想着去兼顾一些可能会有的需求变化或者扩展，比如，是否需要为了之后有可能增加同类的需求去使用抽象类（因为这次新的需求，就是在原来的基础上，抽取仔子集并且加多一些特有的属性）。这些可扩展的设计往往会增加编码的复杂度以及设计开发的时间，好处就是在有扩展需要的时候，会轻松很多。但是以目前三年的开发经验来看，在很多需求都是快速迭代的场景下，需求在原来的基础上扩展情况似乎并不多见，另外则是，在需求有扩展需要的时候，再去抽象重构，似乎总的工作量也没有变化，所以这么看起来还是挺有意思的，因为一直以来的教育和认知都是说设计要考虑扩展性，但是事实是需要结合需求的变化或者需要扩展的可能性，以及设计实现复杂度去综合考虑决策的。如果日后需求变更需要扩展设计，但是成本并不高的话，那么将这种扩展设计放到后续再去实现也是没什么问题的。切记不要过度的设计，合适的设计才是最好的，要去结合需求与实现还有重构的成本去综合考虑设计。记得有一句话说得特别好，好的程序不是一次性设计出来的，而是多次迭代优化出来的。
原文地址：http://www.cnblogs.com/singular/p/16804725.html
