专职DBA-MySQL分库分表

MySQL分库分表
周万春

MySQL为什么要分库分表
常见的分库分表方案
优秀开源中间件推荐
分库分表的二次扩容及缩容实现
业界其它优秀方案

MySQL为什么要拆分？
    单元化，精细治理。

MySQL为什么要分库分表？
    单表行数太多，出现性能拐点。（上千个表，还在增加中）
    单表物理太大，单表50G以上，不方便管理。
    单实例超过1T，不方便管理。
    单表并发太大，锁争用明显。
    实例并发太高，锁争用明显。（thread_running）
    连接数太高。（上千级别）

拆分架构：单元，set化治理思想。

按业务拆分，先拆痛点，先拆核心。
任何不了解业务的拆分，拆完必死。

普通SAS盘能容忍，每张表5个G
PCIE盘SSD盘，能容忍每张表20G

为什么不能用分区表替代分表？
    主要原因：性能问题
        分区表，还是一个表（表级别锁争用明显，特别多分区更新）
        没办法进行多级拆分。
    可以用分区表的地方：
        单分区写入（基于时间的分区）
        没有多机拆分的需求。

不建议分区，分区是个鸡肋，建议是分表。

1.统计每张表发生了多少select,insert,update,delete操作。
    Python:
        mysql-replication-python
    select统计:
        sys.statement_analysis
2.如何统计一下数据里哪些SQL并发度最高。

拆分什么样合理？
    单表不要超过2000万行
    物理大小5-10G（预留20G）

水平拆分：表拆分
垂直拆分：基于业务的拆分。
建议垂直拆：热点业务，DML多的，访问量大的，IO高的。
怎么定位呢？
    看这张表：sys.statement_analysis

业务性能慢：SQL优化--->读写分离（缓存）--->升级硬件--->SQL优化--->读写分离（缓存）--->拆分。
按业务，热点业务拆分出来，设置复制过滤。

基于hash
    userid%100
        user_00
        user_01
        user_..
        user_99
    select ... from user_M where userid=N;
    区间userid
基于range
    区间时间
基于list拆分

大小表拆分（金字塔设计）：年表，月表，天表，十天表。

不是活不下去了，就没有必要考虑分表。
中间件能不用就不用。

优秀开源中间件推荐：
    基于Client端的：Sharding-Sphere（建议 京东金融 https://shardingsphere.apache.org/）
    Sharding-JDBC
    Sharding-Proxy
    基于Proxy模型：DBLE（建议 爱可生 https://github.com/actiontech/dble）目标在于替换MyCAT

主要配置文件：
    rule.xml 分区规则定义，主要和库有关系，没有分表。
    schema.xml 表拆分到分区规则及数据节点的对应。

目前支持分区算法：hash,stringhash,enum,numberrange,patternrange,date,jumpstringhash
DBLE是MyCAT的增强
MyCAT基于Cobber开发
MyCAT太老了，已经不修复bug了，官方放弃维护了。

选择中间件一定要低调
    360公司先开源的Atlas中间件，死掉了
    然后美团接手了，基于Atlas做了个dbproxy，也死掉了
    MyCAT也死掉了
    腾讯TDSQL
    搜狐开源的中间件也死掉了


DBA技能：
    1.MySQL,Redis,MongoDB,ES,
    2.zabbix,open-falcon,
    3.percona-tools,
    4.Xtrabackup,
    5.ProxySQL,MGR,PXC,Xenon,Orchestrator,
    6.OLAP: Clickhouse,
    7.DTS: dataX,yugong,dtle,grvaity,
    8.服务发现类的软件: consul,etcd,DNS:Bind,MyDNS,