MySQL千万级大表优化，看这一篇就忘不掉了( 四 ) _MySQL

采用分区模式：分区模式也是常见的使用方式，采用 hash ， range 等方式会多一些。
在 MySQL 中我是不大建议使用分区表的使用方式，因为随着存储容量的增长，数据虽然做了垂直拆分，但是归根结底，数据其实难以实现水平扩展，在 MySQL 中是有更好的扩展方式。
③读多写少优化场景
采用缓存，采用 Redis 技术，将读请求打在缓存层面，这样可以大大降低 MySQL 层面的热点数据查询压力。
④读少写多优化场景
读少写多优化场景，可以采用三步走：

采用异步提交模式，异步对于应用层来说最直观的就是性能的提升，产生最少的同步等待。
使用队列技术，大量的写请求可以通过队列的方式来进行扩展，实现批量的数据写入。
降低写入频率，这个比较难理解，我举个例子：

对于业务数据，比如积分类，相比于金额来说业务优先级略低的场景，如果数据的更新过于频繁，可以适度调整数据更新的范围(比如从原来的每分钟调整为 10 分钟)来减少更新的频率。
例如：更新状态数据，积分为 200 ，如下图所示：

文章插图

可以改造为，如下图所示：

文章插图

如果业务数据在短时间内更新过于频繁，比如 1 分钟更新 100 次，积分从 100 到 10000 ，则可以根据时间频率批量提交。
例如：更新状态数据，积分为 100 ，如下图所示：

文章插图

无需生成 100 个事务(200 条 SQL 语句)可以改造为 2 条 SQL 语句，如下图所示：

文章插图

对于业务指标，比如更新频率细节信息，可以根据具体业务场景来讨论决定。
架构层优化
架构层优化其实就是我们认为的那种技术含量很高的工作，我们需要根据业务场景在架构层面引入一些新的花样来。

文章插图

①系统水平扩展场景
采用中间件技术：可以实现数据路由，水平扩展，常见的中间件有 MyCAT ， ShardingSphere ， ProxySQL 等。

文章插图

采用读写分离技术：这是针对读需求的扩展，更侧重于状态表，在允许一定延迟的情况下，可以采用多副本的模式实现读需求的水平扩展，也可以采用中间件来实现，如 MyCAT ， ProxySQL ， MaxScale ， MySQL Router 等。

文章插图

采用负载均衡技术：常见的有 LVS 技术或者基于域名服务的 Consul 技术等。
②兼顾 OLTP+OLAP 的业务场景
可以采用 NewSQL ，优先兼容 MySQL 协议的 HTAP 技术栈，如 TiDB 。
③离线统计的业务场景
有几类方案可供选择：

采用 NoSQL 体系，主要有两类，一类是适合兼容 MySQL 协议的数据仓库体系，常见的有 Infobright 或者 ColumnStore ，另外一类是基于列式存储，属于异构方向，如 HBase 技术。
采用数仓体系，基于 MPP 架构，如使用 Greenplum 统计，如 T+1 统计。

数据库优化
数据库优化，其实可打的牌也不少，但是相对来说空间没有那么大了，我们来逐个说一下。

文章插图

①事务优化
根据业务场景选择事务模型，是否是强事务依赖。对于事务降维策略，我们来举出几个小例子来。
降维策略 1：存储过程调用转换为透明的 SQL 调用
对于新业务而言，使用存储过程显然不是一个好主意， MySQL 的存储过程和其他商业数据库相比，功能和性能都有待验证，而且在目前轻量化的业务处理中，存储过程的处理方式太“重”了。