Mysql数据库架构演变历史
单机：请求量大查询慢，单价故障导致业务不可用。
**主从：**数据库主从同步，从库可以水平扩展，满足更大读取需求。但是单服务器TPS，内存，IO都是有限的。
**双主：**用户量级上来后，写请求越来越多。一个Master是不能解决问题的，添加多了个主节点进行写入。多个主节点数据要保持一致性，写操作需求2个master之间同步更加复杂。
分库分表：重点掌握解决方案设计思想，而不是具体框架API调用。如shardingjdbc，tddl，mychat等。
面试题-业务增长数据库性能优化思路讲解
面试题目：我们现在有一个数据库，单表1千万数据，未来1年还会增加500万，性能比较慢，说一下优化思路？
思路：不可以一上来就说分库分表。我们需要结合实际业务情况进行分析。
软优化：
- 数据库参数调优
- 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
- 优化数据库索引结构
- 优化数据库表结构
- 引入NOSQL和程序架构调整
硬优化：
- 提升系统条件（更快的IO，更多的内存），带宽，CPU，硬盘
分库vb 分表：
- 首先我们要确定是什么领域的，外卖，物流，电商还是其他。
- 然后要看分表是否可以满足当前业务的需求和未来增长，数据库分表能够解决单表数据量很大的时，数据库的查询问题。但是无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受到数据库IO性能的限制。
- 如果单分表满足不了业务需求，再进行分库分表。
结论：在数据量及访问压力不是特别大的情况下，首先需要考虑缓存，读写分离，索引等技术。如果数据量极大，且业务持续增长快，再考虑分库分表方案。
Mysql数据库分库分表带来的优点
解决数据库本身瓶颈：
- 数据库连接数过多时，会出现
too many connections的错误，访问量太大或者数据库设置的最大连接数太小的原因。 - Mysql默认的最大连接数为100，可以修改，而mysql服务允许的最大连接数为16384.
- 数据库分表可以解决单台海量数据的查询性能问题。
- 数据库分库可以解决单台数据库的并发访问压力问题。
解决系统本身IO，CPU瓶颈：
- 磁盘读写IO瓶颈，热点数据太多，尽管我们使用了数据库本身缓存，但是依旧有大量IO，导致sql执行速度慢。
- 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长。
- CPU瓶颈，尤其在基础数据数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大，锁冲突，锁等待等原因。
- 可以通过show processlist，show full processlist，发现CPU使用率比较高SQL。常进的对于查询时间比较长，State列值是Sending result，Using filesort等都是可能有性能问题SQL，清楚相关影响问题的情况可以kill掉。也存储CPU占用率高的SQL，通过上面命令查询不到，这个时候最好提供执行计划分析explain进行分析。
Mysql数据库分库分表后六大问题怎么解决？
- **跨节点数据库join关联查询：**数据库切分之前，多表关联查询，可以通过sql join进行实现。分库分表后，数据可能分布在不同的节点上，sql join 带来的问题就比较麻烦。
- **分库分表带来的分布式事务问题：**操作内容同时分布在不同库中，不可避免会带来跨库事务问题，即分布式事务。
- **执行的SQL排序，翻页，函数计算问题：**分库后，数据分布再不同的节点上，跨节点多库进行查询时，会出现limit分页，order by 排序等问题。而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序（也会带来更多的CPU/IO资源损耗）。
- **数据库全局住建重复问题：**常规表的id是使用自增id进行实现，分库分表后，由于表中的数据同时存在不同数据库中，如果用自增id，则会出现冲突问题。
- **容量规划，分库分表后二次扩容问题：**业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容。
- **分库分表技术选型问题：**市场分库分表中间件相对较多，框架各有各的优势与短板，该怎么选择？