MySQL千万级大表优化，看这一篇就忘不掉了!

而在 account 中则是一条 update 语句，如下：

这也是一种很基础的冷热分离，可以大大减少维护的复杂度，提高业务响应效率。

②数据拆分

按照日期拆分：这种使用方式比较普遍，尤其是按照日期维度的拆分，其实在程序层面的改动很小，但是扩展性方面的收益很大。

数据按照日期维度拆分，如 test_20191021。

数据按照周月为维度拆分，如 test_201910。

数据按照季度，年维度拆分，如 test_2019。

采用分区模式：分区模式也是常见的使用方式，采用 hash，range 等方式会多一些。

在 MySQL 中我是不大建议使用分区表的使用方式，因为随着存储容量的增长，数据虽然做了垂直拆分，但是归根结底，数据其实难以实现水平扩展，在 MySQL 中是有更好的扩展方式。

③读多写少优化场景

采用缓存，采用 Redis 技术，将读请求打在缓存层面，这样可以大大降低 MySQL 层面的热点数据查询压力。

④读少写多优化场景

读少写多优化场景，可以采用三步走：

采用异步提交模式，异步对于应用层来说最直观的就是性能的提升，产生最少的同步等待。

使用队列技术，大量的写请求可以通过队列的方式来进行扩展，实现批量的数据写入。

降低写入频率，这个比较难理解，我举个例子：

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

例如：更新状态数据，积分为 200，如下图所示：

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

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

例如：更新状态数据，积分为 100，如下图所示：

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

对于业务指标，比如更新频率细节信息，可以根据具体业务场景来讨论决定。

架构层优化

架构层优化其实就是我们认为的那种技术含量很高的工作，我们需要根据业务场景在架构层面引入一些新的花样来。

①系统水平扩展场景

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

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!