典型问题:

目前可选的在线变更表结构方案有哪些?

在线变更表结构方案如下:

直接 ALTER TABLE

oak-online-alter-table

5.7 新增 online rename index

pt-online-schema-change

OnlineSchemaChange

腾讯 GSC 引擎

自定义脚本

典型问题:

当一个表预期数据量足够大的时候,如何进行分库分表存储,读写分离,来实现高效、稳定的数据存储和读。

分库分表分区是解决大数据量时的一个分而治之的思路,建议依次考虑的顺序如下

1.分区:表分区之后只是引擎存储的工作去保证,对用户相对透明,因为对应用侵入度较低;

2.分表:在同一个 schema 中的多个表,应用可能需要根据业务逻辑去判断业务对应的表,这种情况下单库内路由也相对比较好办;

3.分库:这个方法最大的问题就是分布式事务,目前市场有很多开源中间件可以选择,如当当或者 360 的,但未必能够满足需求,需要进行选择。

其实可以考虑为什么会出现大数据量呢?如果从生命周期角度考虑,对于这样大量的数据,是否可以分为热、温和冷三种类型呢?如果存在,那么:

1)冷数据(历史数据):是否就可以从现行数据表中进行定期剥离呢?比如交易记录,后续只是进行查询,完全可以将完全交易的数据进行定期转存到历史库

2)温数据:对于访问频度相对低一点的数据,如果考虑存储成本,是否可以采用分区的形式将这些数据放在相对廉价的存储上面

3)热数据:对于频繁访问的数据,一般是整个系统的性能瓶颈点,是否可以考虑 SSD 的硬盘,这样能保证既有业务的快速响应

对于数据生命周期的管理还是需要考虑业务实际场景:

当数据量比较大时落地实现的所有功能都交给数据库吗?作为架构设计中的业务架构、应用架构、技术架构、数据架构和部署运行架构中的架构之一,应该是与其他架构设计逻辑整合的一起的,因此需要应用人员和业务人员的参与,有部分功能为了保障数据库整体性能需要提升到应用逻辑中去完成,这样可以更好的提升数据库性能,我们在实战中的一些经验,比如不用存储过程、不用外键、不用复杂表操作,尽量单表操作,这些不是不做了,是数据库不做了,约束交给应用去做了,这样应用在从数据库得到快速响应后可以在应用层面进行逻辑处理,而这种处理的服务器一般可以较好的进行扩展,提高响应能力。(@bryan_sd分享)

典型问题:

1、MySQL 如果单实例,没有主从 单库 ,单表量级达到 5 千万以上,该表的插入和查询都很多, 如何添加修改字段而不产生锁表?

2、如果有主从,表的量级达到千万以上,如何修改添加表字段?是先从库添加完再由从库变更为主库去用,让其在同步么?

1、单实例情况,建议使用 pt 或者 gh-ost 工具,二者均不会产生锁表,前者通过触发器实现,或者通过解析 binlog 实现。

2、多实例情况,如果使用 pt 工具,是在主库做变更;如果使用 gh-ost 工具,主从均可操作。

1.确认表的元数据信息,包括:

字段类型

存储引擎

2.对需求里的改表语句进行审核,如果存在不规范的地方,联系开发进行修正

3.确认当前节点是什么角色,也就是主节点和从节点

4.确认主从状态是否正常

5.根据数据量、业务场景、业务容忍度,选择变更的方案以及预估需要的时间

6.确定操作时间点,如果数据量大,建议在低峰进行

7.通知研发开始进行变更操作,告知研发观察对应业务

8.变更过程中,留意 MySQL 监控和机器监控,观察主从状态、主从连接数、主从机器负载

9.变更过程出现问题,及时 KILL 相关操作

10.变更顺利完成,进行数据校验

11.告知研发

简单列一下:

表名跟业务绑定,表名使用小写字母和下划线命名

除存放日志的表和中间临时表外,其他表原则上必须有主键

创建表必须包含行记录的创建时间字段和修改时间字段

优先选择存储引擎类型为 InnoDB

表和字段必须有 Comment 注释

字符集优先选择 UTF-8

根据数据尺寸决定数据长度,尽量减少冗余

组合索引不能超过5列,最好保持在 3 列以内

组合索引最常使用的字段或区分度高的字段考虑放在索引第一列

索引不宜太多,维护索引也需要成本,单表索引数量建议不超过 5 个

尽量避免使用触发器、存储过程、自定义函数(UDF)、视图

预估容量,是否需要使用分区表,是否需要分表分库

所有字段建议设置默认值,INT 为 0,VARCHAR 为 ''

1.innodb_file_per_table 参数设置为 ON

2.定期执行 OPTIMIZE TABLE tableName;

3.定期执行 ALTER TABLE tableName ENGINE = InnoDB;

注意:第 2、3 条是高危操作,会影响业务,建议在低峰期操作