使用开源产品是一种潮流。在使用之前，我们首先需要对Mysql 有一定的了解，特别是Mysql 的缺点。只有了解其缺点后，我们才知道，能不能真正的应用到我们的业务场景中去。
2.1 Mysql 数据库简介
MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司，现在已经被Sun公司收购，支持FreeBSD、Linux、MAC、Windows等多种操作系统，与其他的大型数据库例如Oracle、DB2、SQL Server等相比功能稍弱一些。
1、可以处理拥有上千万条记录的大型数据
2、支持常见的SQL语句规范
3、可移植行高，安装简单小巧
4、良好的运行效率，有丰富信息的网络支持
5、调试、管理，优化简单（相对其他大型数据库）
2.2 Mysql 优点
- 普及率高
到2017年，Mysql的市场占有率已达44.3%，整个数据库市场，有近一半的企业 选择了Mysql
- 开源社区活跃
Mysql 初始时是开源产品，因此得到很多人的技术支持，在Mysql开源社区 中有大量人为其提交补丁，因此Mysql成熟的速度会越来越高。
- 简单
Mysql 是一个小型 关系型 数据库，其本身结构不复杂，维护技能学习成本 低。而且有大量的资料可以学习。
- 低成本
使用开源产品，可以免去一笔购买产品或者服务的费用 。
- 多引擎适用不同场景
Mysql目前有20多个存储引擎，常用的有memory,innodb,MyISAM. 不同的存储引擎适用不同的场景。
- 开源，可定制
开源产品最大的一个优点，就是可定制。在公司技术人员技术支撑 下开发出最符合本身业务特点的功能、或者是某些插件 。
2.3 Mysql问题说明及建议
1. 对原生JSON格式的支持不足
现代数据存储层通常直接以JSON通信。虽然MySQL和Maria DB现在有能力解析SQL中的JSON部分，但这还远远不够，原生的JSON接口已经被广泛使用于CouchDB、MongoDB，或任何最新的工具中。如果对JSON格式数据处理较多，建议暂时先不用Mysql.
2. join关联性能略低
曾几何时，将数据拆分成多个表代表着计算机科学领域的一大卓越进步。这不仅意味着我们能够显著降低表的大小，同时也为用户带来良好的简化效果。但在JOIN语句当中，这种纪律性与收益开始要求我们为之付出代价。
在SQL当中，还没有哪部分组件能像JOIN这样逼迫开发人员建立一系列复杂语句，并承受由此带来的混乱与绝望。在此之后，存储引擎还需要找到最优方式来高效解压这些JOIN语句。总而言之，这相当于开发人员*建立起复杂的查询表述，而数据库则*对其进行梳理。
正因为如此，很多追求速度表现的开发人员干脆放弃了这一进步，转而采用非规范化方式处理。相较于对条目进行拆分，大家直接将数据对象汇总成一个巨大的表，而这就规避了其复杂性。如此一来，运行速度不仅更快，服务器也不至于(频繁)出现内存溢出状况。
如今磁盘存储空间已经相当廉价。市场上已经出现了单磁盘8 TB产品，而容量更大的方案也即将亮相。所以相信在不久的将来，我们将彻底告别该当活剐的JOIN。
3. 多种引擎
到现在为止，Mysql 的可选引擎已经超过20种，这对于数据库运维人员来说是一件非常头疼的事。不同的存储引擎适用于不同的场景。最常用 的是MyISAM 和innodb。使用MyISAM 存储引擎，却又不支持事务，不能保证数据的一致性。使用innodb，在一定程度是，注意，是一定程度上保证了数据的一致性，却损失了速度。
所以使用Mysql数据库需要清晰明确的了解，哪些业务需要强一致性,需要强一致性的，哪些业务需要高速响应，但是数据不需要处理事务。
建议一般使用innodb 存储引擎，而对事务无要求的数据使用MyISAM 存储引擎，对处理速度要求极高，而且数据本身 并不重要的，可以考虑使用memory 存储引擎 。
这三种引擎，innodb支持璁，但是处理数据速度最慢，MyISAM 不支持事务，处理速度中等，Memory 不会持久化数据，存在数据丢失的问题，速度 最快。
4. 中间件
为了提高执行效率，各个技术大牛们又不得不开发中间件，实现分库分表，垂直拆分和水平拆分等技术。到目前为止，中间件产品已超过10个，但是即使，使用最广泛的Mycat 开源产品，仍存在水平拆分进行分组、聚合查询时出现错误结果的尴尬局面。并且Mycat使用是弱事务（弱事务的问题在于 ，多节点提交时，其中一个节点出现问题无法提交时，其他节点无法回滚）。
所以使用中间件，暂时不建议使用分库分表功能，分库不如直接每个库一个实例。避免因数据量激增而带来的实例拆分 的问题。
- 水平拆分，就是将原本在一张表里的数据，保存在不同节点的同名表里。水平拆分也有优缺点：
优点：
不存在单库大数据，高并发的性能瓶颈。
对应用透明，应用端改造较少。
按照合理拆分规则拆分，join操作基本避免跨库。
提高了系统的稳定性跟负载能力。
缺点：
拆分规则难以抽象
分片事务一致性难以解决。
数据多次扩展难度跟维护量极大。
跨库join性能较差。
垂直拆分（类似于微服务化)，类似于微服务化，将一个功能模块存储在一个库里，这样做有优点也有缺点：
优点：
拆分后业务清晰，拆分规则明确。
系统之间整合或扩展容易。
数据维护简单。
缺点：
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
事务处理复杂。
因此建议：不使用中间件，或者仅使用中间件的读写分离功能。
5. 高可用架构对比
我们常说的Mysql 通常指的是单实例的mysql.而不是高可用集群。官方推出的Mysql 集群有Mysql-cluster，Galera. 其他第三方开发的具有高可用功能的软件有MHA，zookeeper+proxy,共享存储等。下面对其优缺点做下对比：
| 高可用软件 | 硬件要求 | 优点 | 缺点 |
| MHA | 至少3节点 | MHA可以进行故障的自动检测和转移;可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低。一主多从可以保证 数据一致性。 | 1. 至少需要三节点，相对于双节点需要更多的资源; 2. 逻辑较为复杂，发生故障后排查问题，定位问题更加困难; 3. 可能因为网络分区发生脑裂现象; |
| ZOOKEEPER + PROXY | 一般要求，至少2节点。 | 较好的保证了整个系统的高可用，包括proxy 和Mysql； 扩展性好，可以扩展为大规划集群。 | 数据一致性依赖于原生地同步复制 。加入zookeeper 后，整个系统与其他高可用架构相比，极为复杂。 |
| MYSQL-CLUSTER | 官方推荐3节点以上。一个管理节点，两个数据节点。 | 属于内存数据库范围，支持物理存储，运行高效，真正的双活高可用。不依赖第三方软件；实现数据的强一致性 | 配置较复杂。使用NDB存储引擎 ，与常用 的innodb，MyISAM memory 存储引擎略有差异，但是差异 不大。 |
| GALERA | 至少3节点 | 多主写入，无延迟复制，能保证数据强一致性。有成熟的社区 ，有互联网公司在大规模使用，经验丰富，架构成熟。自动故障转移，自动添加，删除节点。 | 需要 为原生 的Mysql 打wsrep补丁，只支持innodb 存储引擎， |
| 共享存储 | 一般要求，至少2节点 | 部署简单，切换逻辑简单。很好的保证数据的强一致性。不会因为 Mysql本身逻辑错误引发不一致的情况。 | 需要考虑共享存储的高可用价格高昂。 |
综上，我们选择Galera 架构，实现强一一致性，保证 高可用 ，自动添加删除节点，这些是其他方案所无法比拟的。有大规模应用经验，而其他很多架构的应用不够广泛。因此，从其功能性的完善，保证强数据一致性，运行高效方面 三者合一，是其他方案所无所比拟的。