周一夜间进行了一次XX业务相关的数据库表优化。
原因：
一共4张表，数据量不大，最小的40万记录，最大的300万，大小不超过300MB。但由于历史原因，表没有建立索引，对应的服务使用的SQL千姿百态，修改起来难度有点大，容易改错，涉及的全国客户较多，大部分都是全表扫描，在秒级的响应时间，但大多客户还能忍着。
目标：
对于此类无法通过建立索引提高响应速度的表，采用降低数据量，即水位线的方式，提高全表扫描的效率。
方案：
经过多次改进，行程可用的方案：
第一部分：
1、CREATE TABLE XXX_20130910 AS SELECT * FROM XXX;
利用原表建立一个中间表。
2、TRUNCATE XXX;
Truncate原表。
3、INSERT INTO XXX SELECT * FROM XXX_20130910 WHERE 7天;
将7天的数据插入原表。
此时启动相应服务，这个过程可以保证利用最短的时间恢复生产表的使用。
第二部分：然后建立历史表：
1、CREATE TABLE XXX_HISTORY AS SELECT * FROM XXX_20130910 WHERE 1<>1;
利用中间表建立一个空的历史表。
2、建立夜维，用于每天将生产表7天之前的数据导入历史表。
整体操作完成后，用于生产的表保持7天的数据量，即使业务量增加，水位线也不会上升太多，保持在一定的高度。同时通过将生产表历史数据导入历史表的方式，既保证了历史数据的备份，也保证了生产表的数据量。
上线：
第一部分包括检查的时间总共耗时20分钟。与用户确认测试后开始第二部分，大约用时10分钟。
效果：
当天上线后的效果还可以，大多应用的响应时间从秒级，下降到xx毫秒级，有待一段时间内的查看。
总结：
整体过程经过来多次修改与总结，且为上线当天整理了步骤手册，标明了每步的操作以及注意的地方，所以操作当天比较顺手，主要是与多个客户联系停止应用、测试应用比较耗时，不同的客户配合的程度不同，不过还算是比较配合。
对于数据库表的优化，以上操作其实已经精简到最简单的语句了，我觉得优化操作不在于多么的复杂，最重要的是简单、有效、安全，何况是没有用户驱动的优化，做好了可能不会说你什么，但做错了就有人叫了，得不偿失，因此不同的优化操作，可能选择的方法不同，但核心应该坚持“简单、有效、安全”，这样才能做到画龙点睛的效果。个人见解，欢迎拍砖！