MySQL内核开发者, 《高性能MySQL 第三版》译者之一,活跃于MySQL社区,BugList,etc...
本文主要简单介绍下8.0.17新引入的功能multi-valued index, 顾名思义,索引上对于同一个Primary key, 可以建立多个二级索引项,实际上已经对array类型的基础功能做了支持 (感觉官方未来一定会推出类似pg的array 列类型), 并基于array来构建二级索引,这意味着该二级索引的记录数可以是多于聚集索引记录数的,因而该索引不可以用于通常意义的查询,只能通过特定的接口函数来使用,下面的例子里会说明。
如下worklog列出来的功能将在未来某个版本被废弃,因为大部分不符合SQL标准,或者用处不大且会引起用户困惑。如果您的应用依赖于某个功能,需要尽快改掉,以避免在未来升级版本时出现语法错误。 WL#12615: Deprecate SQL_CALC_FOUND_ROWS and FOUND_ROW...
MySQL8.0.17推出了一个重量级的功能:clone plugin。允许用户可以将当前实例进行本地或者远程的clone。这在某些场景尤其想快速搭建复制备份或者在group replication里加入新成员时非常有用。
前言 CTE也就是common table expressions是sql标准里的语法,很多数据库都能够支持,MySQL也在8.0版本里加入了CTE功能,本文主要简单的介绍下该语法的用法,由于笔者对server层了解不深,本文不探讨代码层 CTE与derived table最大的不同之处是 可以自引用,递归使用(recursive cte 在语句级别生成独立的临时表. 多次调用只会执行一次 一个cte可以引用另外一个cte 一个CTE语句其实和CREATE [TEMPORARY] TABLE类似,但不需要显式的创建或删除,也不需要创建表的权限。
InnoDB在设计lock-free的log system时,除了已有的参数外,还通过宏控制隐藏了一些参数,如果你使用源码编译时,打开cmake选项-DENABLE_EXPERIMENT_SYSVARS=1, 就可以看到这些参数了。
即使MySQL8.0已经GA了,官方仍然在向其中增加新的功能,比如在最新的MySQL8.0.16版本中,增加了一个众望所归的功能:CHECK CONSTRAINT,也就是说可以自动对写入的数据进行约束检查。
MySQL8.0里引入了不少关于权限的改动,从这些改动可以看出来,权限管理更加的规范和遍历了,这和我们之前为rds mysql增加了大量权限管理很类似,想来Oracle也是通过这些改动为其云业务服务的吧。
缓存管理是DBMS的核心系统,用于管理数据页的访问、刷脏和驱逐;虽然操作系统本身有page cache,但那不是专门为数据库设计的,所以大多数数据库系统都是自己来管理缓存。由于几乎所有的数据页访问都涉及到Buffer Pool,因此buffer pool的并发访问控制尤为重要,可能会影响到吞吐量和响应时间,本文主要回顾一下MySQL的buffer Pool最近几个版本的发展(若有遗漏,欢迎评论补充), 感受下最近几年这一块的进步 MySQL5.5之前 只能设置一个buffer pool, 通过innodb_buffer_pool_size来控制, 刷脏由master线程承担,扩展性差。
本文主要描述下MySQL8.0在网络模块的几个小优化, 由于本人对server层代码不熟悉,所以只是列出自己的理解和相关的patch以及worklog,不做深入详细实现的解释,感兴趣的可自行从连接中找到对应的代码 admin Port 运维大并发负载数据库的同学经常会碰到的情况是,max_connection被占满,甚至root账户都无法登陆上去,kill掉这些链接来让实例恢复正常。
MySQL从8.0.13版本开始支持一种新的range scan方式,称为Loose Skip Scan。该特性由Facebook贡献。我们知道在之前的版本中,如果要使用到索引进行扫描,条件必须满足索引前缀列,比如索引idx(col1,col2), 如果where条件只包含col2的话,是无法有效的使用idx的, 它需要扫描索引上所有的行,然后再根据col2上的条件过滤。
MySQL从5.7版本开始支持Generated Column, 并在最近的8.0版本中支持了Functional index, 这两个特性都通过创建使用表达式进行描述的列来实现的。笔者之前满好奇这些表达式信息都是怎么存储的,本文主要记录了涉及到的相关函数,主要是做个笔记,不会深入解读。
最近的MySQL8.0.14版本增加了其第一个并行查询特性,可以支持在聚集索引上做SELECT COUNT()和check table操作。本文简单的介绍下这个特性。 用法 增加了一个session级别参数: innodb_parallel_read_threads 要执行并行查询,需要满足如下条.
前言 InnoDB的undo log从5.6版本开始可以存储到单独的tablespace文件中,在5.7版本支持了在线undo文件truncate,解决了长期以来的undo膨胀问题。而到了8.0版本,对Undo tablespace做了进一步的优化:在新版本中,我们可以拥有更多的回滚段(每个Undo tablespace可以有128个回滚段,而在之前的版本中所有tablespace的回滚段不允许超过128个),减少了由于事务公用回滚段产生的锁冲突;可以在线动态的增删undo tablespace,使得undo的管理更加灵活。
temptable engine 我们知道UNION, DERIVED TABLE, CTE, 子查询或者distinct order by之类的查询都可能用到临时表来存储中间结果,官方文档中列举了几种场景。
前言 MySQL8.0.13版本开始支持使用表达式或函数来作为索引键值,这使得索引的定义更加灵活,一些运算可以直接转移到索引上去。 实际上在之前的版本,我们也可以通过在generated column上创建索引的方式来实现类似功能, root@test 05:20:44>CREATE TABLE .
前言 在MySQL8.0之前的版本中,innodb btree索引中的记录都是严格按照的key的顺序来存储的,但有些时候当我们需要倒序扫描时,效率就会很低。为了解决这个问题,从MySQL8.0版本开始支持在索引Key中倒序存储。
前言 在MySQL8.0之前的版本中,由于架构的原因,mysql在server层使用统一的frm文件来存储表元数据信息,这个信息能够被不同的存储引擎识别。而实际上innodb本身也存储有元数据信息。这给ddl带来了一定的挑战,因为这种架构无法做到ddl的原子化,我们在线上经常能够看到数据目录下遗留的临时文件,或者类似server层和innodb层列个数不一致之类的错误。
MySQL8.0开始对一些DDL操作做了大量的优化,例如原子DDL, 快速DDL(只修改元数据),前者解决了长期以来mysql的一大诟病,后者则提升了dba同学的生活品质 官方文档列出了一些可以快速ddl的操作,大体包括: 修改索引类型 Add column (limited) 当一条alt.
在之前,笔者介绍过InnoDB对于lob列的更新优化,即允许对lob类型的列数据进行部分更新。由于undo log page本身的限制(例如无法存储过长的数据),对于大列更新,旧版本被留在数据文件中,在MVCC读时,直接从中读旧版本即可。
MySQL当前已经发布到MySQL8.0版本,在新的版本中,可以看到MySQL之前被人诟病的优化器部分做了很多的改动,由于笔者之前的工作环境是5.6,最近切换到最新的8.0版本,本文涵盖了一些本人感兴趣的和优化器相关的部分,主要包括MySQL5.7的cost model以及MySQL8.0的直方图功能。
MySQL8.0对json进行了比较完善的支持, 我们知道json具有比较特殊的存储格式,通常存在多个key value键值对,对于类似更新操作通常不会更新整个json列,而是某些键值。 对于某些复杂的应用,json列的数据可能会变的非常庞大,这时候一个突出的问题是:innodb并不识别json类型,对它而言这些存储统一都是LOB类型,而在之前的版本中Innodb处理LOB更新的方式是标记删除旧记录,并插入新记录,显然这会带来一些存储上的开销(尽管Purge线程会去后台清理),而写入的redo log和Binlog的量也会偏高,对于超大列,可能会严重影响到性能。
背景 当前几乎所有的关系数据库都采用日志先行的方式,也就是所谓WRITE-AFTER-LOG(WAL),这是因为日志通常是顺序写的,并且写入量相比修改的数据通常要小很多。通过redo log来确保提交的事务必然具有持久性。
熟悉InnoDB的朋友都知道,innodb的history list长度代表了有多少undo日志还没有被清理掉,可以通过show engine innodb status 命令来获得。如果发现history list的长度越大,要么就是实例的复杂非常高,要么就是可能有大查询,或者事务没提交,导致Undo log无法分析。
Note: 当前版本为MySQL8.0.3 InnoDB的undo log是其实现多版本的关键组件,在物理上以数据页的形式进行组织。在早期版本中(
传统的事务锁赋予方式是采用FIFS先来先服务的方式,从MySQL8.0.3开始,引入了一种新的模式CATS调度方式,全称为Contention-Aware Transaction Scheduling (或者叫做VATS, V=Variance). 顾名思义就是能够感知到事务竞争关系来实现全局最小开销的锁调度方式。
Note1: 本文所有代码相关的内容都是基于MySQL8.0.3,而目前版本还处于RC和快速开发的状态,不排除后面的版本逻辑,函数名等发生变化。Note2: 主要代码在这个commit 中,感兴趣的也可以自行阅读代码Note3: 本文仅是本人的阅码笔记,记录的比较凌乱。
在MySQL5.7之前的版本中, InnoDB每次做crash recovery之前都需要扫描数据目录,打开每个文件并创建内存对象。当目录下文件个数特别多时,会严重影响到崩溃恢复的速度。 为了解决这个问题,MySQL5.7通过结合checkpoint + 标注被修改的文件的方式,从一个check
众所周知,由于MySQL采用统一Server层+不同的底层引擎插件的架构模式,在Server层为每个表创建了frm文件,以保存与表定义相关的元数据信息。然而某些引擎(例如InnoDB)本身也会存储元数据,这样不仅产生了元数据冗余,而且由于Server层和引擎层分别各自管理,在执行DDL之类的操作时,很难做到crash-safe,更别说让DDL具备事务性了。
PS: 本文内容基于MySQL8.0.0版本,由于目前才Release了第一个开发版本,不排除后续行为会发生变化 相信很多朋友都有这样的体验,在实例启动的时候动态修改了某些配置,但是忘了修改配置文件,结果实例一重启修改就丢失了。或者对于诸如部署在云上的业务(例如RDS),通常用户是没有修改配置文件
Role功能可以说是一个期待已有的功能,这从它的Worklog号(WL#988)就可以看出来,这是个相当早并且呼声很高的需求了。 所谓Role,可以认为是一个权限的集合,这个集合有一个统一的名字,就是Role名,你可以为多个账户赋予统一的某个Role的权限,而权限的修改可以直接通过修改Role来实
之前一直没去了解这快,这两天正好工作中碰到,这里简单记录下data directory的相关代码,InnoDB不支持INDEX_DIRECTORY,不在本文的讨论范围内. 以下涉及代码部分基于MySQL5.7.12 创建表 在建表时指定DATA DIRECTORY,如下所示: mysql>
Query Rewrite Plugin 从MySQL5.7.6版本开始支持Rewrite Plugin,可以将符合条件的SQL进行重写。在真实世界中,这个特性还是非常有用的,例如错误的上线了某个SQL,但由于无法走到索引导致全库; 或者你可能使用某个第三方的已编译好的软件,但SQL可能执行错误,
一直以来MySQL在GIS上的功能支持都比较弱,并且仅有MyISAM引擎支持。很高兴的看到MySQL5.7将这个短板补上了,实现了InnoDB引擎的GIS支持,现在对GIS数据可以支持完整的MVCC和事务特性。在MySQL5.7版本里,针对GIS特性主要做了几点改进: 1. InnoDB支持Spa
最近有幸前去美国参加Percona Live 2016会议并分享了我们最近在MySQL复制上所做的工作,也就是基于InnoDB的物理复制。会后很多小伙伴私信我说分享的PPT太内核了,不太容易理解。因此本文主要针对分享的内容进行展开描述,希望能对大家有所帮助。 背景知识 在开始之前,你需要对Inn
用sysbench去压测开启了semisync的实例, 拿pt-pmp抓下调用栈, 一目了然
varchar是变长字符串呀,设置大了不会产生实际浪费.
配置要根据你自己的机器来设定啊,比如Buffer pool size,能大尽量大;如果你的写入负载很大的话,redo log文件尽量配大点,防止频繁checkpoint导致的性能衰减;还有Lru scan depth,page cleaner线程个数来优化后台刷脏; 2. 另外看你是否需要强持久化,比如sync_binlog是否设为1, innodb flush log at commit也设为1 这都对性能有所影响(但强持久化数据),看你自己的取舍和实际场景.
官方不给推荐配置是有理由的。。。。没有十全十美的配置,只有适合自己业务和服务器的
RR级别在MySQL里意味着在一个事务活跃期间,快照会一直打开,这可能会导致Undo/垃圾数据不能及时清理,Undo空间膨胀。没啥业务上必须的理由,尽量用RC
没get到问题点, 你问的是客户端如何发起回滚么 ??