共计 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 行业资讯频道！
