产品中心
在数据库的维护当中对表的垂直才分是必然的，基本上在业务刚开始准守 3NF 是明智的，当然也可以有一些反范式的设计。但是，建议还是应该在3NF的基础上再酌情考虑反范式。
当遇到真的要对一些表进行拆分，那要拆那些字段嘞？下面我们就来分析一下。
在新业务上线后导致TPS突然增高，这时我们对新上的业务又不是很懂。而问题又要分析解决。
这边使用到了 吴炳锡 大神的一个工具 parsebinlog
该工具可以解析出表的操作情况
链接: https://github.com/wubx/mysql-binlog-statistic
上面工具只能解析单个binlog文件的操作，如果要解析多个文件的可以使用 笔者的工具 pasrebinlog_stat.py
pasrebinlog_stat.py 是对执行parsebinlog解析完之后的数据进行的统计生成excel文件的工具
具体使用方法(在github最后有一点小小的说明):https://github.com/daiguadaidai/mysql-binlog-statistic
使用笔者的方法统计后会生成 5 个文件:
如这边我在sort_by_update.xls文件中看到 t1 表在定义行，说明他的总update量最多。
然后在format.txt找到 t1 表的统计格式如下：
知道了哪个表的那个字段update频繁，可以先将字段从表中剥离出单独的表。至于需要不要开另外的库需要看会不会对其他主要业务有影响（如：下单付款等）。如果有影响在拆到其他库中。
拆出来的目的主要是为了让每一个page能存储更多的数据，并且不会让 t1 表的数据在缓存中能保存的更长久，不会出现平凡的age out 显现(没有解决TPS高的问题)。
第一种：将TPS分散，也就是需要将表进行分区到不同库(一般这样要考虑的东西太多。数据量不大一般不考虑)
第二种：使用能提供更高TPS的产品（这边建议 redis 是不错的选择）。
这边排除第一种
使用第二种：
更具时间经验值：一般使用redis 能提供 TPS:3-5W 更具机器情况还有所提高。
QPS:7-10W 更具机器情况还有所提高。
对于我们的TPS的情况 3-5W TPS 的redis一般能够胜任
这边主要担心的就是有关 持久化 的问题，这就是架构上需要设计的了。
步骤可以有：
最终配合redis的架构图：
