当MySQL单表记录过大时，CRUD的效率会受到很大的影响，可以参考如下方式进行优化。
- 限定数据范围
务必限制不带任何限制条件的查询，比如查询历史数据的时候，可以限制在1周或者一月。 - 读写分离
经典的数据库拆分方案，主库负责写，从库负责读。 - 垂直拆分
根据数据库表中的相关性进行拆分，比如用户相关的放到用户数据表（库），订单相关的放到订单数据表（库）。简单说就是：数据表*列的拆分
- 垂直拆分的优点：简化表结构，使得表易于维护。读取时由于列变少了，可以减少网络消耗。
- 垂直拆分的缺点：需要管理冗余列，需要使用join操作。事务会变得复杂。
- 水平拆分
数据列不变，通过某种规则将数据分散到不同的表或者库中。可以支撑非常大的数据量。
注意，分表只能解决单一表过大，由于数据还在同一台机器，无法解决高并发问题，所以水平拆分最好分库。
水平拆分能够支持非常大的数据量存储，应用端改造也小。但是分布式事务难以解决，跨节点性能较差，逻辑复杂。尽量不要对数据进行分片。因为这会带来逻辑、部署、运维的各种复杂度。一般情况优化得当可以支持千万级数据。一定要分片的话，尽量选择客户端分片，这样可以减少一次和中间件的网络IO。
5.对于分库分表的原则主要有以下几点：
①.如果在性能上没有瓶颈点那么就尽量不做分库分表；
②.如果要做，就尽量一次到位，比如说16库64表就基本能够满足为了几年内你的业务的需求。
③.很多的NoSQL数据库，例如Hbase，MongoDB都提供auto sharding的特性，如果你的团队内部对于这些组件比较熟悉，有较强的运维能力，那么也可以考虑使用这些NoSQL数据库替代传统的关系型数据库。
最后，你在使用一个方案解决一个问题的时候一定要弄清楚原理，搞清楚这个方案会带来什么问题，要如何来解决，要知其然也知其所以然，这样才能在解决问题的同时避免踩坑。
