MySQL数据库的字段什么时候可以拆分

68次阅读
没有评论

共计 2099 个字符,预计需要花费 6 分钟才能阅读完成。

这篇文章主要为大家展示了“MySQL 数据库的字段什么时候可以拆分”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让丸趣 TV 小编带领大家一起研究并学习一下“MySQL 数据库的字段什么时候可以拆分”这篇文章吧。

在数据库的维护当中对表的垂直才分是必然的,基本上在业务刚开始准守 3NF 是明智的,当然也可以有一些反范式的设计。但是,建议还是应该在 3NF 的基础上再酌情考虑反范式。

当遇到真的要对一些表进行拆分,那要拆那些字段嘞? 下面我们就来分析一下。

在新业务上线后导致 TPS 突然增高,这时我们对新上的业务又不是很懂。而问题又要分析解决。

分析解决步骤

解析近期生成的 binlog 文件获得是哪个表哪个字段操作的多。

这边使用到了 吴炳锡 大神的一个工具 parsebinlog。

该工具可以解析出表的操作情况。

上面工具只能解析单个 binlog 文件的操作,如果要解析多个文件的可以使用 笔者的工具 pasrebinlog_stat.py。

pasrebinlog_stat.py 是对执行 parsebinlog 解析完之后的数据进行的统计生成 excel 文件的工具。

具体使用方法 (在 github 最后有一点小小的说明):https://github.com/daiguadaidai/mysql-binlog-statistic。

使用笔者的方法统计后会生成 5 个文件:

ll

-rw-rw-r– 1 manager manager 58191 Sep 6 17:18 format.txt

-rw-rw-r– 1 manager manager 100352 Sep 6 17:18 sort_by_delete.xls

-rw-rw-r– 1 manager manager 100352 Sep 6 17:18 sort_by_insert.xls

-rw-rw-r– 1 manager manager 100352 Sep 6 17:18 sort_by_total.xls

-rw-rw-r– 1 manager manager 100352 Sep 6 17:18 sort_by_update.xls

如果关心 update 操作可以查看 sort_by_update.xls 其中是按 update 操作次数降序排列的。

然后根据要了解的 表名 到 format.txt 中查看哪个字段更新平凡。

查看解析出的文件相关 excel

如这边我在 sort_by_update.xls 文件中看到 t1 表在定义行,说明他的总 update 量最多。

然后在 format.txt 找到 t1 表的统计格式如下:

Table `app_db`.`easy_channel_item`:

Type TOTAL opt: 440353

Type INSERT opt: 8049

Type DELETE opt: 1419

Type UPDATE opt: 430885

28 col : 517

23 col : 145

7 col : 379383

6 col : 46449

12 col : 2

13 col : 2

9 col : 21

8 col : 21

5 col : 4102

4 col : 3853

26 col : 3

27 col : 173

21 col : 136

24 col : 3

25 col : 116

从上可以很清楚的看到 6 col 和 7 col 操作占用了大多的 update 操作。

通过查看数据库表结构可以知道这两个字段分表是 price 和 inventory。

拆分字段

知道了哪个表的那个字段 update 频繁,可以先将字段从表中剥离出单独的表。至于需要不要开另外的库需要看会不会对其他主要业务有影响 (如:下单付款等)。如果有影响在拆到其他库中。

拆出来的目的主要是为了让每一个 page 能存储更多的数据,并且不会让 t1 表的数据在缓存中能保存的更长久,不会出现平凡的 age out 显现 (没有解决 TPS 高的问题)。

对于要提高 TPS 一般有两种方法

第一种:将 TPS 分散,也就是需要将表进行分区到不同库 (一般这样要考虑的东西太多。数据量不大一般不考虑)。

第二种:使用能提供更高 TPS 的产品 (这边建议 redis 是不错的选择)。

这边排除第一种

使用第二种:

更具时间经验值:一般使用 redis 能提供 TPS:3-5W 更具机器情况还有所提高。

QPS:7-10W 更具机器情况还有所提高。

对于我们的 TPS 的情况 3-5W TPS 的 redis 一般能够胜任

这边主要担心的就是有关 持久化 的问题,这就是架构上需要设计的了。

redis 自身具有持久化功能,每秒持久化一次。

更具我们 同步的情况其实同步可以忍受短时间不实时现象。如果出现 redis 失效 (宕机或怎么的可以重启 redis 重新同步所有数据)。

可以搭建 redis 的 master-slave 或 cluster 都行这样就能很好的解决一台 redis 宕机问题。

可以根据 数据库软件设计的某些原理和借鉴秒杀架构,在后台不定期的将 redis 的数据同步到 MySQL。

步骤可以有:

先将相关数据 格式化 的写入到日志文件 (有能力提供消息队列更好)。

写入日志成功之后再将数据在 redis 做操作。确保出问题有数据库可查。

以上是“MySQL 数据库的字段什么时候可以拆分”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注丸趣 TV 行业资讯频道!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-15发表,共计2099字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)