mysql数据库可靠性分析

mysql数据库有undo空间5种mysql做可靠性分析的方案：1．MySQL Clustering(ndb-cluster stogare)简介：MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。成本：节点服务器对RAM的需求很大，与数据库大小呈线性比例；最好使用千兆以太网络；还需要使用Dolphin公司提供的昂贵的SCI卡。优点：可用于负载均衡场合；可用于高可靠性场合；高伸缩性；真正的数据库冗余；容易维护。缺点：随着数据库的变大，对RAM的需求变得更大，因此成本很高；速度：几乎 比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍。应用场合：冗余，高可靠性，负载均衡2. MySQL / GFS-GNBD/ HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？GFS/GNBD可以提供所需的共享硬盘。GFS是事务安全的文件系统。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，其他作为备份服务器。优点：高可靠性某种程度的冗余按照高可靠性进行伸缩缺点：没有负载均衡没有保证的冗余无法对写 *** 作进行伸缩速度：单独服务器的2倍。对读 *** 作支持得较好。应用场合：需要高可靠性的、读 *** 作密集型的应用3. MySQL / DRBD / HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？DRBD可以提供这样的共享硬盘。DRBD可以被设置成事务安全的。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，而其他则作为备份服务器。优点：高可靠性；一定程度的冗余；以高可靠性名义来看是可伸缩的。缺点：没有负载均衡没有保证的冗余在写负载方面没有伸缩性速度：在读写方面相当于单独服务器应用场合需要高可靠性、读 *** 作密集型的应用4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)简介：考虑不同的读、写DB数据库连接的情况。可以使用一台主服务器用于写 *** 作，而采用n台从服务器用于读 *** 作。成本：最多1台高性能写服务器，n台读服务器的成本优点:读 *** 作的高可靠性；读 *** 作的负载均衡；在读 *** 作负载均衡方面是可伸缩的。缺点：无写 *** 作的高可靠性；无写 *** 作的负载均衡；在写 *** 作方面无伸缩性；速度：同单独服务器；在读 *** 作方面支持得较好应用场合读 *** 作密集型的、需要高可靠性和负载均衡的应用。5. Standalone MySQL Servers(Functionally separated) (Active)多台功能分离的单独服务器，没有高可靠性、负载均衡能力，明显缺点太多，不予考虑。

mysql>create table user(cardNum int)

Query OK, 0 rows affected (0.11 sec)

mysql>create table borrow(cardNum int,foreign key(cardNum) references user(carNum))

Query OK, 0 rows affected (0.16 sec)

mysql>

InnoDB存储数据字典，这意味着MyISAM已经可以完全从MySQL数据库中剥离；

Invisible Index，Inside君对这个特性非常感兴趣。因为在生产环境中，可以通过sys库判断哪些索引是冗余的。但是要直接删除冗余索引又担心会存在一些风险。Invisible Index给了我们很好的选择；

角色表功能，官方MySQL终于提供了Role功能。InnoSQL傲娇的表示我们在5.5就实现了此功能，甚至比MariaDB还要早。要知道在游戏行业，定期密码修改总是一个令人头疼的问题，有Role就简单多了。当然，InnoSQL还可以对Role进行资源控制，不知道8.0实现的怎样；

Cost Model改进，优化器能够感知到页是否存在缓冲池中。5.7其实已经开放接口，但是不对内存中的页进行统计，返回都是1.0；

直方图支持，MySQL也支持直方图啦。应该会有更好的执行计划。海翔兄在IMG大会中说到过此特性，听说性能提升非常不错；

参数持久化，继续与Oracle数据库靠近，但本身这个特性就是硬需求。话说这些年有多少因为没有参数持久化导致的坑发生；

扫描性能的改进，InnoDB全表扫描或范围查询性能提升5%~20%。请问之前HT写的代码有这么烂？

重构BLOB的实现，从而提升JSON属性的更新。个人感觉这方面性能的提升可能会非常大。留个爪，后面进行测试；

持久化自增值，这些年淘宝、Percona都做过类似的改进。但是官方的修改就是优雅，自增写redo，一个历史遗留难题就这么简单而又优雅的解决了；

PS库添加索引，官方宣称添加了100多个索引。的确，Inside君遇到过很多时候PS库占用20G内存的场景，这时查询就会显得非常不高效。但是内存开销会不会进一步提升呢？让我们拭目以待吧；

---