mysql高可用方案对比 支撑日活百万用户的高并发系统，应该如何设计其数据库架构？ ？

支撑日活百万用户的高并发系统，应该如何设计其数据库架构？ ？

以mysql为列：

1：支撑高并发系统，一定会涉及事务，所以数据库引擎必选innodb，innodb支持事务，事务级别根据业务而定，如果业务数据一致性要求很高，事务就开启序列化级别，这样就完全隔离事务，但是会导致锁资源竞争加剧。mysql的性能有一定的降低。

2：读写分离，数据库分成主库和从库，主库负责写数据，丛库负责读数据。注意主从数据库数据一致性问题。

3：冷热数据分离，美团，饿了么部分设计采用冷热数据分离，拿订单来说，已送达订单，主要的业务场景就是查询，越往前的数据查询的概率就越低。这就是冷数据。正在交易的订单就是热数据，需要时时查询和更新。对于冷数据，可以放到redis缓存。这样会增加查询效率。

4：数据表设计，充分利用索引查询。业务sql避免返回无用的行和列，禁止使用select *查询，查询的时候加limit，尽可能返回满足要求的行。对于复杂的sql，考虑拆分sql，拆分sql有一个好处，重复查询的sql，第二次查询会放到mysql的缓冲区，避免重复操作磁盘，提高访问的性能。

5：分库分表。比如业务数据按月分等。一定程度缓解增删改查的压力。

希望对你有一定的帮助。谢谢。

写入mysql数据库的数据量很大，数据库架构该怎么去设计？

对于这种大数据量系统业界已经有不少成熟方案

最简单的是读写分离，写操作只在主库写，配置自动同步到从库。部分读操作改成操作从库，减少主库数据库压力。

还可以让给应用加一个redis缓存，查询时先读缓存，读不到再读数据库。

如果改成这样，压力还是太大，就要考虑分表。

分表思路很多，例如把热点数据放一张表，非热点数据放一张表。或者按用户id尾号做hash，分表分布在不同表。

如果读写要求已经超过单机支撑能力，那就要考虑集群，你可以搜索一下怎么用mycat搭建数据库集群

mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？

mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：

1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法

2 读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步

3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库

4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*)， in，递归等消耗性能的语句

5 用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。

上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。

当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧

mysql高可用方案对比 高可用架构设计 mysql高可用方案推荐

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。