我想许多公司的研发或者DBA都会碰到一个问题，MySQL在处理海量数据上往往力不从心，硬件是一个因素，自身缺乏对复杂SQL处理，也是一个硬伤。但事实也没有那么糟糕，MySQL对于绝大部分公司来说，也是够用的，如果每个公司都创建自己的一套海量数据分析平台，使用hadoop等各类分析框架/平台/工具，反而难以取得好的收益。我们投入到设计/策略的时间越多，我们越能获得更好的投入/产出比。充分利用现有的技术和标准的产品/组合，往往可以取得 更好的效益，除非事实证明，你需要在某个时间点重构你的分析平台了。

许多项目在上线的时候，其实并没有充分想好数据的处理和分析，如果项目进展很快，数据量爆炸式增长，基于原有的数据做分析，往往会出现一些问题，所以在项目上线之前，就考虑好数据的记录和分析是有必要的，并不是要求每个业务，都单独搭建自己的一个统计库/分析平台，但你需要有所准备。

如下是一些OLAP的大的原则和方向，

1、MySQL实例控制在几个2个T以内，是DBA们比较赞同的策略，OLAP数据库可以大到几个T，但是备份之类的操作很耗时，percona工具之xtrabackup可以比较好的备份大数据库；

2、对于数据分析，应该尽量避免重复计算，对于报表之类的应用，最好定期生成统计表，基于统计表，可以快速的查看统计数据，而不需要从原始数据表里去扫描统计大量数据；

3、对于旧数据的归档/清理，需要考虑，理论上来说，如果你的设计比较完善，绝大部分时候，你已经不需要原始数据了，保留统计表数据即可，你可以定期把原始数据清理掉。 原始数据也可以以其他的方式，比如日志的方式，存储在其他介质；

4、为了节省空间，我们可能会设计一些代码/映射表，通过在一些大表中仅仅存储代码/数字的方式，我们可以大大减少存储的空间，对于oltp业务，我觉得没有必要这样做，程序/数据的可读性，自然会更重要，但对于OLAP数据库，这样真的可能节省大量磁盘空间；

5、索引的滥用可能会是一个问题，如果你拥有大量的数据，索引带来的大量随机读其实效率很低，也延缓了数据插入的速率。你需要仔细检查，确保仅仅创建需要的索引；

6、使用LOAD DATA 的方式加载数据很快，值的优先考虑，你也可以使用批量insert的方式，one by one的导入大量数据的方式太过低效，不可取。 当然使用insert批量插入数据也没有必要一次性插入太多记录，100～1000记录每个语句一般是可以接受的；

7、如何避免导入数据对于线上业务的影响需要考虑，你可能需要中间表，你可能需要额外的从库；

8、对于超大规模的海量数据，单个节点可能难以容纳和处理，使用分区表某种程度上可以加快一些分析/查找，但仍然受限制于单个节点，在单个节点已经无法处理海量数据的时候，你应该考虑sharding的策略。