MySQL:: MySQL 8.0参考手册::15.12.2联机DDL性能和并发

10bet网址

版本8.0

5．7
5．6

8.0日本

MySQL 8.0参考手册/....../ 在线DDL性能和并发性

15.12.2 DDL在线性能和并发性

在线DDL改进了MySQL操作的几个方面:

访问表的应用程序响应速度更快，因为在进行DDL操作的同时，对表的查询和DML操作可以继续进行。减少对MySQL服务器资源的锁定和等待可以带来更大的可伸缩性，即使是对于不涉及DDL操作的操作。
即时操作仅修改数据字典中的元数据。表中没有拍摄元数据锁，表数据不受影响，瞬间进行操作。并发DML不受影响。
在线操作避免与表复制方法关联的磁盘I / O和CPU循环，从而最大限度地减少数据库上的整体负载。最小化负载有助于在DDL操作期间保持良好的性能和高吞吐量。
在线操作将数据缩小到缓冲池中的数据库，而不是表 - 复制操作，从而减少了从内存中的频繁访问数据的清除。频繁访问的数据清除可能导致DDL操作后临时性能浸。

锁子句

默认情况下，MySQL在DDL操作期间使用尽可能少的锁定。的锁如果需要，可以指定用于就地操作和一些复制操作以强制执行更多限制性锁定。如果是锁子句规定了比特定DDL操作允许的限制性锁定级别，但语句因错误而失败。锁条款的限制性按从少到多排列如下:

锁=没有：
允许并发查询和DML。
例如，使用此子句进行涉及客户注册或购买的表，以避免在冗长的DDL操作期间使表无法使用。
锁定=共享：
允许并发查询，但阻止DML。
例如，在数据仓库表上使用此子句，可以将数据加载操作延迟到DDL操作完成，但查询不能延迟很长时间。
锁定=默认值：
允许尽可能多的并发（并发查询，DML或两者）。省略这一点锁子句与指定相同锁定=默认值．
使用此子句时不希望DDL语句的默认锁定级别导致表格的任何可用性问题。
锁=独家：
阻止并发查询和DML。
使用此子句如果主要问题是在最短的时间内完成DDL操作，并且不需要并发查询和DML访问。如果服务器支持空闲，则可能还使用此子句，以避免意外表访问。

在线DDL和元数据锁

可以查看在线DDL操作有三个阶段：

阶段1：初始化
在初始化阶段，服务器将考虑存储引擎功能、语句中指定的操作和用户指定的操作，确定在操作期间允许多少并发性算法和锁选项。在此阶段期间，采用共享可升级元数据锁定来保护当前表定义。
第二阶段:执行
在此阶段，陈述是准备和执行的。元数据锁是否升级为独占才能取决于初始化阶段中评估的因素。如果需要一个独占元数据锁定，则仅在语句准备期间简要拍摄。
第3阶段：提交表定义
在提交表定义阶段中，元数据锁定升级为独占才能驱动旧表定义并提交新表。曾经授予，独占元数据锁的持续时间是简短的。

由于上面概述的独占元数据锁需求，在线DDL操作可能必须等待持有表上元数据锁的并发事务提交或回滚。在DDL操作之前或期间启动的事务可以在被更改的表上持有元数据锁。在长时间运行或非活动事务的情况下，在线DDL操作可能会因等待独占元数据锁而超时。此外，在线DDL操作请求的挂起的排他元数据锁会阻塞表上的后续事务。

下面的示例演示了一个等待独占元数据锁的在线DDL操作，以及一个挂起的元数据锁如何阻塞表上的后续事务。

第1节：

MySQL>创建表T1（C1 INT）引擎= InnoDB;mysql>开始交易;mysql>从t1中选择*;

会议1选择语句接受表t1上的共享元数据锁。

第2届：

MySQL> Alter Table T1添加列X INT，算法= inplace，LOCK = NONE;

会话2中的在线DDL操作需要表t1上的独占元数据锁来提交表定义更改，必须等待会话1事务提交或回滚。

第3节：

mysql>从t1中选择*;

的选择会话3发出的语句被阻止等待所请求的独占元数据锁定ALTER TABLE要授予会话2中的操作。

您可以使用显示完整的流行列表确定事务是否正在等待元数据锁定。

mysql>显示完整的processlist \ g ... *************************** 2.行*************************** ID：5用户：root host：locthost db：test命令：查询时间：44状态：等待表元数据锁定信息：alter表t1添加列xint，algorithm = inplace，lock = none ... *************************** 4.行**************************** ID：7用户：root主机：locthost db：test命令：查询时间：5状态：等待表元数据锁定信息：选择*来自t1套装4行（0.00秒）

元数据锁定信息也通过性能架构公开metadata_locks表，它提供关于会话之间的元数据锁依赖关系、会话正在等待的元数据锁以及当前持有元数据锁的会话的信息。有关更多信息，请参见第27.12.13.3节“Metadata_Locks表”．

在线DDL性能

DDL操作的性能主要由操作是否立即执行，到位，以及它是否重建该表。

要评估DDL操作的相对性能，可以使用算法=瞬发，算法=原地，和算法=复制．语句也可以使用old_alter_table使能强迫使用的算法=复制．

对于修改表数据的DDL操作，可以通过查看”行受影响”命令执行完毕后显示的值。例如:

更改列的默认值（快速，不影响表数据）：
```
查询OK，受影响0行(0.07秒)
```
添加索引(需要时间，但是0行受影响显示该表未复制）：
```
查询OK, 0行受影响(21.42秒)
```
更改列的数据类型（需要大量的时间并需要重建表的所有行）：
```
查询确定，影响1671168行（1分35.54秒）
```

在在大型表上运行DDL操作之前，请检查操作是否快速或缓慢，如下所示：

克隆表结构。
使用少量数据填充克隆表。
在克隆表上运行DDL操作。
检查是否”行受影响”值是否为零。非零值意味着操作复制表数据，这可能需要特殊的规划。例如，您可以在计划停机期间执行DDL操作，或者在每个副本服务器上一次执行一个DDL操作。

请注意

为了更好地了解与DDL操作相关的MySQL处理，检查性能架构和Information_Schema.与之相关的表格Innodb.在DDL操作之前和之后，查看物理读取，写入，内存分配等的数量。

Performance Schema阶段事件可用于监视ALTER TABLE的进步。看到第15.16.1节，“使用性能模式监视InnoDB表的ALTER TABLE进程”．

因为有一些处理工作涉及到记录并发DML操作所做的更改，然后在最后应用这些更改，所以在线DDL操作可能会比阻止其他会话访问表的表复制机制花费更长的时间。原始性能的降低与使用表的应用程序更好的响应能力相平衡。在评估更改表结构的技术时，要考虑最终用户对性能的感知，基于web页面加载时间等因素。

上一个首页向上下一个