微软。
成都创新互联主要从事成都网站建设、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务那坡,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792
MySQL，虽然功能未必很强大，但因为它的开源、广泛传播，导致很多人都了解到这个数据库。
MySQL开发人员需要新功能，而MySQL8.0在诸如SQL，JSON，正则表达式和GIS等领域提供了许多新的和更多需求的功能。开发人员也希望能够存储Emojis，因此UTF8MB4现在是8.0中的默认字符集。最后，数据类型得到了改进，在BINARY数据类型上进行了按位操作，并且改进了IPv6和UUID功能。微软（Microsoft）是一家美国跨国科技企业，由比尔·盖茨和保罗·艾伦于1975年4月4日创立。最为著名和畅销的产品为Windows操作系统和Office系列软件，是全球最大的电脑软件提供商、世界PC（PersonalComputer，个人计算机）软件开发的先导。
如果我们查看“top”命令的输出，我们会看到：MySQL 5.7
MySQL 8.0
这也展示出 MySQL8 使用的更多常驻内存和虚拟内存。特别是“可怕的”虚拟内存，因为它远远超过这些 VM 上可用的 1GB 物理内存。当然，虚拟内存使用（VSZ）是现代应用程序实际内存需求的一个很差的指标，但它确实证实了更高的内存需求这个事。
实际上，正如我们从 “vmstat” 输出中所知道的那样，即使没有太多的“空间”，MySQL 8 和 MySQL 5.7 都不会在低负载下使用 swap 分区。如果您有多个连接或希望在同一个 VM 上运行某些应用程序，则可以使用 swap（如果未启用交换，则可能导致 OOM）。
这是一个有趣的实验，能看看我有多少可以驱动 MySQL 5.7 和 MySQL 8 的内存消耗。
测试mysql5.7和mysql8.0 分别在读写、只读、只写模式下不同并发时的性能（tps，qps）
机器
myql5.7.22
mysql8.0.15
sysbench
mysql5.7和mysql8.0 在读写模式下的表现
双1 配置，读写模式下，mysql5.7.22 和mysql8.0.15 tps 、qps 性能差不多，mysql8.0.15 在120 线程并发时，性能出现了下降抖动：
mysql5.7和mysql8.0 在只读模式下的表现
双1 配置，只读模式下，mysql5.7.22 的tps、qps比mysql8.0.15 好1/3 左右；并发线程数增加后，tps、qps并没有随着增加，反而出现了下降的趋势：
mysql5.7和mysql8.0 在只写模式下的表现
双1 配置，只写模式下，随着并发数的上升，mysql5.7.22 的性能比mysql8.0.15 好1/4左右
mysql5.7和mysql8.0 在读写模式下的表现
0 2配置，读写模式下，并发数低时，mysql5.7.22性能好于mysql8.0.15; 并发数比较高时，mysql8.0.15 性能好于mysql5.7.22；在80 线程的并发以上时，性能开始下降
mysql5.7和mysql8.0 在只读模式下的表现
0 2配置，只读模式下，mysql5.7.22性能比mysql8.0.15 好1/3左右；随着并发数的上升，性能也没有上升，反而有下降的趋势
mysql5.7和mysql8.0 在只写模式下的表现
注意
sysbench 需要设置--db-ps-mode=disable 禁用预编译语句，不然并发测试线程多时会报下面的错误
使用脚本
mysql8 可以说是一个质的飞越。增加了很多新特性，以及提高了各方面的速度。增加了开窗函数
Ⅱ InnoDB增强
自增列方面
自增列方面。现在自增列计数器会在每次值修改时，将值写到REDO LOG中，并且在CHECKPOINT时写到存储引擎私有的系统表中。
这就消除了以往重启实例自增列不连续的问题（这也可能形成了一个新的竞争点（盖国强会上提问InnoDB开发者））。
Btree索引方面
Btree索引被损坏。InnoDB会向REDO LOG中写入一个损坏标志。同时也会CHECKPOINT时将内存中损坏页的数据记录到存储引擎私有的系统表中。
这也就促成了恢复时。两边一致的情形。索引不可用，并不会造成实例起不来。这很大程度上降低了之前使用innodb_force_recovery和innodb_fast_shutdown的必要。
提升了一致性。（对于一般DBA来说透明，知道有这么回事就好）
NoSQl操作
InnoDB memcached插件支持多个get操作（在单个memcached查询中获取多个键/值对）
和范围查询。（个人认为这个挺牛逼，有点像NoSQL，不仅仅是NoSQL）。
需要安装daemon_memcached插件，其中多了一个innodb_memcache schema,这个schema中有几张表,其中一张containers用来与InnoDB表之间做映射,，
然后通过接口访问Innodb表。然后会有一个11211的端口打开，用于建立连接。
好处是通过减少客户端和服务器之间的通信流量，在单个memcached查询中获取多个键/值对的功能可以提高读取性能。
对于InnoDB来说，也意味着更少的事务和开放式表操作。
死锁检测
新的动态配置选项innodb_deadlock_detect可用于禁用死锁检测，默认打开。 在高并发系统上，当大量线程等待相同的锁时，死锁检测会导致速度下降。 有时，在死锁发生时，
禁用死锁检测并依赖innodb_lock_wait_timeout设置进行事务回滚可能更有效。记得之前版本遇到死锁会自动回滚。以下截图来自MySQL5.7，与8.0默认相同。
（也就是说即便MySQL5.7也是有死锁检测的，并且自动回滚权重较小的事务（套死除外））。
尝试更改innodb_deadlock_detect参数为OFF。则遇到死锁时两个工作线程都会被堵塞。直到innodb_lock_wait_timeout设定的锁超时。
新的INFORMATION_SCHEMA.INNODB_CACHED_INDEXES表保存了Innodb索引缓存在Innodb buffer pool中的页数。
现在，所有InnoDB临时表都将在共享临时表空间ibtmp1中创建。
加密特性
支持REDO和UNDO表空间加密。
共享锁方面
InnoDB在 SELECT ... FOR SHARE 和 SELECT ... FOR UPDATE锁定读语句上 支持不等待（ NOWAIT）和跳过锁（SKIP LOCKED）的选项。也就是说以往加了共享锁之后必须手动释放。
这里如果没有锁就返回结果，如果有就报下面错误。
如果是用有锁就跳过，则无数据。
根据场景使用。反正都是秒回。降低了排查数据库超时的可能。
