mysql分库分表实践1

分区方法：
1、range
2、hash
3、路由规则规定哪个库

可用性–> 复制一份数据(数据一致性)
双主问题，同时写库，数据会不一致，同一ID会同时写入
注：只允许一个写入

可用性 一致性

读写走主?
id中午化

缓存与数据库数据不一致
双淘汰

无缝导库
什么情况会导库?
1). 实践: 分库，扩容，库迁移与拆分
2). 实践: 数据库迁移, mongo => mysql
3). 实践: 数据库增加字段 => 能 alter table么? (不能在线增加)
解决方案:

1. 停服务 => 业务能接受的话，强烈建议
2. 无缝方案

实践: 追日志倒库
目标

1. 1个库分成4个库
2. 多个库部署到多台物理机上
   解决方案
   如果回滚?

实践: 双写倒库
目标

1. 数据由 mongo 迁移到mysql(增加字段同样适用)
2. 不停止对外服务

数据量大?

拆库，四类典型场景
如何拆？拆库依据是什么?

(单key) 用户库如何拆分: user(uid, XXOO)
(1对多) 帖子库如何拆分: tiezi(tid, uid, XXOO)
(多对多) 好友库如何拆分: friend(uid, friend_uid, XXOO)
(多key) 订单库如何拆分: order(oid, buyer_id, seller_id, order_info, XXOO)

帖子库，以帖子ID作为拆分依据

好友表拆分，是做两份数据，成功一次做个日志，每天定时扫描，来保证数据一致性

订单表,百分之八十根据oid查询，百分之二十根据买家ID来查询，百分之一根据卖家ID查询

冗余数据，即多做一份数据，进行处理

分库后业务实战即拆完库之后会有什么问题？

海量数据下Mysql怎么玩
互联网公司少量数据下，以下不会使用：
1、各种连接
2、子查询
3、触发器
4、用户自定义函数
5、…
6、"事务"都用的很少(跨库事务)
为什么？

以上业务是逻辑层的，就放在逻辑层来解决，数据库只做数据的增删查改

实战-IN查询怎么做？
查询需求：IN查询：where uid IN(1,2,3,4,5,6)
解决方案：服务做MR
(1) 直接分发 (分配给所有的库都查)
(2) 拼装成不同SQL 分析ID，查出在哪个库，就查哪个库

不是主键的查询，如头像查询 条件是：用户帐号
解决方案：只定位一个库，随机时

跨库分页查询怎么做？
需求：order by xxx OFFSET xxx LIMIT xxx
(1) 按时间排序
(2) 每页100条记录
(3) 取第100页的记录

单机方案
order by time OFFSET 10000 LIMIT 100
分库后如何实现？
分库后难点：如何全局排序？
传统做法：SQL改写 + 自己排序取数据
(1) 每个库 order by time OFFSET 0 LIMIT 10100
(2) 对所有库 取的数据进行排序
(3) 返回第 10000 至 10100条的数据

方案一：
(1) 技术上，引入特殊ID，作为查询条件(或者带入上一页的排序条件)
(2) 业务上，尽量禁止跨页查询

单机情况
(1) 第一页，直接查
(2) 得到第一页的max(id)=123 (一般是最后一条记录)
(3) 第二页，带上 id > 123 查询：where id>123 LIMIT 100
这样每次只要查100条，那分库情况呢？

分库情况 (假如3个库)
(1) 将where id > xxx LIMIT 100 分发
(2) 将300条结果排序
(3) 返回前100条

方案二:
(1) 业务上：禁止查询xx页之后的数据
(2) 业务上：允许模糊返回 => 第100页数据的精确性真这么重要么?

总结
(1) 分片
(2) 复制
(3) 分组
(4) 路由规则

分布式，软件架构带来的问题
可用性 ==> 复制，一致性
读写笔 ==> 增加从库，缓存，索引，