这时我轻轻地闭上了眼睛，我好像来到童话世界，好像在和小鸟讨论秋天的美景，好像在和小草拍秋天的照片。农民伯伯在田野里收获了庄稼，果农们在果园里收获了果子，我们在学校里收获快乐、收获知识、收获成长。
前言
我们都知道初创公司一开始都是以单体应用为首要架构，一般都是单体单库的形式。但是版本以及版本的迭代，数据库需要承受更多的高并发已经成了 架构设计 需要考虑的点。
那么解决问题，就得说到方案。但是方案有很多，我们该怎么选择呢？
优化与方案
基本上，我们优化要从几个关键字入手： 短距离 ， 少数据 ， 分散压力 。
短距离
所谓的短距离，指的是从前端到数据库的路径要短。
- 页面静态。有些页面的数据是在某些时段是不变的，那么这个页面可以静态化，这样可以提高访问的速度。
- 使用缓存。缓存大家都知道，快的原因就是基于内存。所以使用基于内存的缓存的话，可以减少对数据库的访问，同时加速访问速度。
- 批量读取。高并发的情况下，可以将多个请求的查询合在一次进行，以减少对数据库的访问速度。
- 延迟修改。延迟修改的意思高并发的情况西可能是将多次修改数据放在缓存中，然后定时将缓存中的数据过更新到数据库；也可以是通过缓存的同步策略通过解析异步同步到数据库中。
- 使用索引。这个不用说了，索引有着比较多的类型，例如普通索引/主键索引/组合索引/全文索引等。
少数据
所谓的少数据，其实是查询的数据要少。
- 分表。所谓的分表，其实有水平切分和垂直拆分。玩过单机的小伙伴都知道，往往一些具有历史性的表单，都会有成百上千万级别的数据。这样子对于 MySQL 来说，即使是加了索引，SQL 方面继续优化，也很难做到更快的查询速度。那么我们可以通过分表的操作来实现。例如说最常见的我们可以根据时间的维度来进行表的水平拆分，今年的数据保持下来，而去年的数据可以存在另外一个表里。
- 分离活跃数据。其实这个有点类似缓存，但是不同之处在于数据还是在 MySQL 上面的。例如一个查询商品的业务，有一些火爆/经常被搜索的商品可以存在一张活跃表。查询的时候先查询活跃表，没有的话再查询总商品表。
- 分块。这个分块有点类似于算法里面的“索引顺序查找”。通过数据层面的优化，将数据放在不同的块中，而我们只需要计算找到对应的块就行了。
分散压力
所谓的分散压力，其实是分散不同数据库服务器的压力
- 集群。集群的概念相信大家都很清楚，对于业务服务器来说其实就是具备相同业务流程的服务器部署多台，通过负载均衡或其他方式来将请求分配到不同服务器。而数据库也一样，通过特定的规则策略将数据导向特定的数据库服务器上。
- 分布式。所谓的分布式，其实就是将原本处于同个流程的业务逻辑分配到不同的服务器上面执行，达到了“并发”执行的效果，加快执行速度。
- 分库分表。分库分表主要是水平拆分和垂直拆分。对于访问频率高而数据量巨大的单表，可以减少单表的数据，根据特定的维度进行水平拆分，增加数据库的吞吐量，这就是 分表水平拆分 ；而对于业务耦合性低的多表来说，可以将不同的表存储在不同的数据库上，对数据库进行垂直拆分，提高数据库写的能力，即 分库的垂直拆分 。
- 建立主从。建立主从的目的其实就是为了读写分离。我们都知道，只要数据库的事务级别够高，那么并发读是不会影响到数据的混乱，而并发写则会。所以建立主从一般来说，写会留在主服务器上写，而会在从服务器上读。 所以基本上让主服务器进行事务性操作，从服务器进行 select 查询。这样子的话，事务性操作（增加/删除/修改）导致的改变更新同步到集群中的从数据库 。
结语
以上就是MySQL 如何处理高并发的详细内容，更多关于MySQL 高并发的资料请关注其它相关文章！
