=========优化的顺序===============
（是根据MySQL优化的效果和优化所需的成本）
第一 优化你的sql和索引；
sql中的一些in、join等子查询效率完全可以用表连接来代替；索引一般是根据sql语句来建立，并且最好和主键或者用户常用的条件相关。
第二 做归档，可以根据表数据的业务类型进行归档。也可以看做是表的数据条数拆分。
比如tc_history库的数据，根据时间进行归档操作，将原来的trade_order_detail表按某时间字段（一般以有索引的业务时间字段midified）拆分为trade_order_detail_2013等等。
第三 加缓存，memcached,redis；
缓存式数据库需要搭配源码搭建的数据库。与阿里云的RDS估计不大行。
第四 主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以用三方工具，第三方工具推荐360的atlas；
第五 mysql自带分区表，对应用透明，无需更改代码，但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，；
第六 先做垂直拆分，其实就是根据模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；
第二点的归档操作需要考虑归档表对业务上的影响（比如归档之后的表是否只需要查询，可以合理更换引擎tokudb等等）；
第七 水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；
水平切分大致就是指将一张数据表中的字段切分，然后存储在多个数据表中，但这样的话，势必会需要程序代码和数据结构有较大的改动。
例如根据tenant取模来分库就是横向扩展；分库会使单表的数据量减少（tc减半），数据量一旦减小的话，很多问题都可以迎刃而解。
（拆分来提高表的访问效率：）
=====综合业务特点=======
对于一个存储设计，必须考虑业务特点，收集的信息如下：
1.数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；
表informaton_schema.tables 字段：table_rows和avg_row_length
2.数据项：是否有大字段，那些字段的值是否经常被更新；
字段类型是否有text或者blob；另外varchar字段为null的数据，索引效率也是极其低的。
3.数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；
一般出现order by create_Date这些语句的时候，表的设计一刚开始就应该设计为id自增，然后以id 去order by 或者直接找到准确的id
4.数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；
5.SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？
6.预计大表及相关联的SQL，每天总的执行量在何数量级？
7.表中的数据：更新为主的业务 还是 查询为主的业务
8.打算采用什么数据库物理服务器，以及数据库服务器架构？
9.并发如何？
10.存储引擎选择InnoDB还是MyISAM？
一般会选择使用innodb引擎，表结构不方便更改的情况下，多利用内存，减轻IO负载，数据库的瓶颈一般都会卡在IO上；