mysql分库分表的一些记录

一，按业务维度拆分
比如一个系统可能包含了用户，商品，订单业务，由于这三个维度在访问与数据读写上不平衡，为避免互相影响，提高性能，可以按业务维度拆分成用户系统，商品系统与订单系统。

二，数据归档
针对有的数据只需要留存而不涉及到读写，可以考虑将其归档。像一定时间前的访问日志

三，读写分离
对于某个系统来说，当其发展到一定阶段，数据库必然会成为瓶颈，可以先考虑实现读写分离以减轻对主库的压力，实现的方式大致有两种：

• 中间件路由。在应用与数据库之间，由中间件将请求转发到读库或写库。相关的中间件有：Amoeba，MySQL-Proxy，MaxScale，MyCat等。
• 应用内部实现路由。应用与数据库直连，由应用来定使用读库或写库。相关技术有spring 动态数据源,Sharding-JDBC等。

使用中间件的优点是对业务透明，不用修改代码，缺点是加长了调用链路，增加了故障点、降低了性能；而在应用内部进行路由则相反。
另外实现了读写分离需要考虑下面几个问题：

1. 故障转移的问题。相关的技术有MHA，keepalive，MyCat等。
2. 如果是使用应用进行的路由，则需要在应用里配置读写数据源。
3. 主从延迟的问题。针对这个问题一方面看能不能从业务上规避，如果规避不了则有针对性的将相关读服务连主库。另一方面如果读性能瓶颈很大，可以直接考虑使用缓存代替，用缓存分片来应对数据量大的问题。

四，分表分库
数据量大到一定程度后，数据库的读写性能会下降，更别说那些较复杂的查询，一般业说单表数据达到千万级别就算是量很大，需要考虑拆分存储了。就单库而言，并发达到2000已经算是性能很不错了，如果再大就避免不了分库。简单一句：数据量大，就分表；并发高，就分库。

4.1分片策略

• 范围分片
  优：增加或减少分片时基本不涉及数据迁移，扩展性强
  劣：易出现热点数据
• HASH分片
  优：数据分布均匀
  劣：增加或减少分片时涉及数据迁移，不利扩展
• 查表法
  优：可以较灵活的制定映射算法，扩展性较强
  劣：映射表可能成为热点表，可以考虑加缓存

4.2分片需要考虑的问题

1. sharding key的选择
   如何确定分片键的时候需要根据业务来定，可以在多个维度将分片键与其它常用字段进行冗余存储。
2. 分布式事务
3. 分布式主键ID
   可以考虑使用全局生成主键表，雪花算法等。
4. 跨库JOIN，翻页等
   常用的做法是将全量数据存入es或使用hive；进行数据冗余；借助中间件；能否从业务上限制。
5. 扩容前后数据能否落在同一张表，如果不是则需要数据迁移，像这种情形需要尽量避免

五，平滑切换到新库

1. 双写，同时在写与读的过程中加上开关，在一定范围内进行灰度运行。
2. 老数据进行同步，这个可以通过程序进行同步也可以监听binlog。
3. 数据比对，这个是确认新老库是否数据一致的。

这篇文章写的很好，深入分析了各种分库分表算法的利弊，特别提出了常见的错误做法：分库分表
还可以参考：每日百万订单，这样的技术方案更靠谱