分库分表
1.数据量太大，SQL查询慢怎么办？
从sql语句入手
- exist和in
- in 和 not in
- like
从数据库设计入手
- 加索引（不是越多越好）
- 尽量多考虑使用数值型，（性别，int 1,0；不用char 1,0）
- 尽量多考虑使用定长而非变长（idNumber varchar(11)）
2.mysql
单表存储上限：$(2^{32})^2$
- 理论上限，实际上是达不到的：实际行数上限还受myisam_data_pointer_size限制
- 第二个上限是表的存储空间大小限制（Storage limits）：256TB
3.千万级别的表查询怎么优化？
- 相关字段加索引
- 优化SQL查询语句
- 不解决，把坑留给后面的接手的客户和程序员
- 加缓存，如：redis，memcached
- 数据库读写分离
- 数据库拆分
4.分库分表，怎么分
- 把原本存储在同一个库的数据分块存储到多个库上，把原来存储在一个表中的数据分块存储到多个表上。
- 分库分表目的：分散单台设备负载
常用切分方案：
A：垂直（纵向）拆分
- 按照不同的表（或者Schema来切分割到不同的数据库（主机）之上）
B：水平（横向）拆分
- 根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台 数据库（主机）之上。
- C:垂直水平拆分
5.分库分表的解决方案
应用层
- 当当[sharding-jdbc]，阿里[TDDL]
Proxy 中间层
- 社区：Mycat（cobar）
- 数字：Atlas，金山：kingshard，百度：heinsberge
- 商业版：Oneproxy，youtube：vitess
- 方案比较
| Cobar | TDDL | ShardingJDBC | Mycat | |
|---|---|---|---|---|
| 分库支持 | Yes | Yes | Yes | Yes |
| 分表支持 | No | Yes | Yes | Yes |
| 框架类型 | Proxy | 应用集成 | 应用集成 | Proxy |
| 中间层 | Yes | No | No | Yes |
| ORM支持 | 任意 | 多种 | 多种 | 多种 |
| 数据库支持 | mysql | 多种 | 多种 | 多种 |
| 外部依赖 | No | Diamond | No | No |
| 社区活跃度 | 停滞 | 停滞 | 较活跃 | 活跃 |
| 文档丰富 | Yes | 中等文本 | Yes | Yes |
| 持续更新 | No | 中等文本 | Yes | Yes |
6.Mycat分库分表原理和实现
- 分片规则和策略 ---> 多种分片规则策略，还可以自定义
- 分布式全局唯一ID ---> 多种分布式全局唯一ID实现
- 多数据源管理问题 ---> 统一管理所有数据源
- 跨域跨表join问题 ---> 全局表/sharedjoin/catlet
其他特点：
- 独创ER关系分片，解决ER分片难处理问题
- 采用全局分片技术，每个节点同时并发插入和更新数据，都可以读取数据
- 通过人工智能的Caltlet支持分片复杂SQL实现以及存储过程支持等。
通俗易懂解析MyCat
- mycat就是一个数据库中间件，数据库的代理，它屏蔽可物理数据，应用连接mycat，然后mycat再连接物理数据库
- 它支持水平拆分（分库分表，通过分库达到分表），支持多种分片规则。比如：范围切片、自然月分片、hash取值分片等
- 它支持mysql、oracle、mongodb、sql server，并支持数据库集群。
MyCat核心配置文件
- server.xml 配置连接mycat的用户名、密码、数据库名
- schema.xml 配置schema，datanode，datahost
- rule.xml 分片规则
7.Mycat分库分表后的问题
垂直拆分带来的问题：
- 部分业务表无法join，只能通过接口方式，提高了系统复杂度
- 存在单表性能瓶颈，不易扩展
- 事务处理复杂
水平拆分带来的问题：
- 拆分规则难以抽象
- 分片事务一致性难以解决
- 维护难度较大
- 跨表join性能差
