写在建库前：

在确定数据库业务后、建立数据库表格时，就应对一些常见问题有所考虑，以避免在数据增长一段时间后再做应对，可能造成时间及维护成本增加：

  • 数据的月增量，年增量
  • 数据的快速增长点
  • 是否需要触发器或事件等
  • 查询业务需求
  • 服务器访问量

以上的考虑项，对数据库的类型、表的结构、表间关系的定义及数据库配置都有非常重要的影响。

 

运行后优化：

优化顺序

第一，优化你的sql和索引；

　　想实现一个查询，可以写出很多种查询语句，不同的语句，根据你选择的引擎、表中数据的分布情况、索引情况、数据库优化策略、查询中的锁策略等因素，最终查询的效率相差很大；优化要从整体去考虑，有时你优化一条语句后，其它查询反而效率被降低了，所以要取一个平衡点。

第二，加缓存，memcached,redis；

第三，主从复制或主主复制，读写分离；



分区表，先试试这个，对你的应用是透明的，无需更改代码,但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，另外 分区表还有一些坑；（分区表的使用还是有所保留，貌似目前的 分区键设计还不太灵活，如果不走分区键，很容易出现全表锁；另外一旦数据量并发量上来，如果在分区表实施关联，就是一个灾难。）



第五，如果以上都做了，那就先做垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；

第六，才是水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；