mysql5.7怎么样 mysql57bug

MySQL 5.7 vs 8.0 , 哪个性能更牛?测试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 禁用预编译语句,不然并发测试线程多时会报下面的错误
使用脚本
优化体系--详解MySQL 5.7虚拟列,值得收藏 我们都知道where条件如果在字段上带了函数就不会去走索引,不好优化,无意间了解到mysql一个新特性--虚拟列 , 专门处理这块问题的,下面一起来了解下吧~
在MySQL 5.7中,支持两种Generated Column,即 Virtual Generated Column和Stored Generated Column ,前者只将Generated Column保存在数据字典中(表的元数据),并不会将这一列数据持久化到磁盘上;后者会将Generated Column持久化到磁盘上,而不是每次读取的时候计算所得 。很明显,后者存放了可以通过已有数据计算而得的数据 , 需要更多的磁盘空间,与Virtual Column相比并没有优势,因此,MySQL 5.7中 , 不指定Generated Column的类型,默认是Virtual Column 。
如果需要Stored Generated Golumn的话,可能在Virtual Generated Column上建立索引更加合适 。综上,一般情况下,都使用Virtual Generated Column,这也是MySQL默认的方式
假设有一个表,其中包含一个 date 类型的列 `SimpleDate` date
SimpleDate 是一个常用的查询字段,并需要对其执行日期函数,例如
此时的问题是 即使对 SimpleDate 建立索引,这个查询语句也无法使用,因为日期函数阻止了索引 。
为了提高查询效率,通常要进行额外的操作,例如新建一个字段 SimpleDate_dayofweek,存放 dayofweek(SimpleDate) 的计算结果 , 然后对这列创建索引,SimpleDate_dayofweek 的值需要程序写入 , 例如使用触发器,在 SimpleDate 有变动时更新这样查询就可以改为
这么做的好处是提高了查询性能,可以使用 SimpleDate_dayofweek 列的索引了 , 但又带来了其他麻烦,例如
虚拟列Generated Columns 就是用来解决这个问题的,可以增加一个可被索引的列,但实际上并不存在于数据表中,下面用一个实验来说明下:
需求:为了实现对json数据中部分数据的索引查询,考虑用MySQL5.7中的虚拟列功能
1、创建表
2、准备数据
3、构建姓名的虚拟列
4、构建索引
5、测试是否用到索引
可以看出用了索引了
6、插入新数据
此时的表的结构由于多出了user_name这一虚拟列,再插入别的数据要注意在表后指明插入列(不能给虚拟列插入数据)

推荐阅读