10bet网址
MySQL 5.6参考手册
相关的文档10bet官方网站 下载本手册 本手册摘录

18.1.7.3 NDB集群事务处理限制

关于交易的处理,NDB集群中存在许多限制。这些包括以下内容:

  • 交易隔离级别。ndbcluster.存储引擎仅支持阅读承诺交易隔离级别。(InnoDB例如,支持阅读承诺读未提交可重复读取,可序列化的)。你应该记住这一点NDB实施阅读承诺在每场基础上;当读取请求到达存储行的数据节点时,返回的是当时的行的最后一个已提交版本。

    未返回未提交的数据,但是当与读取相同行的事务修改许多行同时提交交易,执行读取的事务可以观察到之前价值观,由于可以在其他事务的提交之前或之后可以处理给定的行读取请求,因此对于这些不同行之间的值或两者。

    为了确保给定的交易仅在值之前或之后读取,您可以使用以下命令锁定选择...锁定分享模式。在这种情况下,锁定直到拥有交易承诺。使用行锁也会导致以下问题:

    • 锁等待超时错误的频率增加,并发性降低

    • 由于需要提交阶段的读取,增加了事务处理开销

    • 有可能耗尽可用数量的并发锁,这是有限的MaxNoofConCurrentopoperations.

    NDB使用阅读承诺对于所有读取,除非修饰符如锁定共享模式更新使用。锁定共享模式导致使用共享行锁;更新导致使用排他的行锁。唯一密钥读取会自动升级它们的锁NDB确保读取自洽;读取还采用额外的锁定以获得一致性。

    第18.5.8.4节“NDB群集备份故障排除”,有关NDB集群如何实现事务隔离级别的信息可能会影响备份和恢复的信息NDB数据库。

  • 唯一的键查找和交易隔离。唯一的索引是实施的NDB使用内部维护的隐藏索引表。当一个用户创建的NDBTable使用唯一索引访问,首先读取隐藏的索引表以找到主键,然后使用主键读取用户创建的表。为了避免在这个双读操作期间修改索引,在隐藏的索引表中找到的行将被锁定。当一行被用户创建的唯一索引引用时NDB表已更新,隐藏索引表由执行更新的事务受到独占锁定的影响。这意味着任何在同一个读取操作(用户创建的)NDB表必须等待更新完成。即使读取操作的交易级别是这样的,这也是如此阅读承诺

    可以用来绕过潜在阻塞读取的一种变通方法是强制SQL节点在执行读取时忽略惟一索引。可以通过使用忽略索引索引提示作为其中的一部分选择语句读取表(参见第8.9.3节“指数提示”)。因为MySQL Server为每个创建的唯一索引创建阴影有序索引NDB,这使得读取有序索引,并避免唯一的索引访问锁定。生成的读取与主键读取的已提交的读取一样一致,返回读取行时的最后一个已提交的值。

    通过订购索引读取群体较少使用群集中的资源,并且可能具有更高的延迟。

    还可以通过查询范围而不是查询惟一值来避免使用惟一索引进行访问。

  • 事务和blob或text列。ndbcluster.仅存储使用任何MySQL的列值的一部分文本表格中的数据类型可见MySQL;其余的文本存储在一个单独的内部表中,MySQL无法访问。这就产生了两个相关的问题,您在执行时应该注意这两个问题选择包含这些类型列的表的语句:

    1. 对于任何一个选择来自NDB群集表:如果选择包括A.文本列,阅读承诺事务隔离级别转换为带读锁的读级别。这样做是为了保证一致性。

    2. 对于任何一个选择使用唯一键查找检索使用任何文本数据类型并且在事务中执行,共享读锁定在表中保持在表中的持续时间 - 即,直到事务被提交或中止。

      对于使用索引或表扫描的查询,甚至是针对索引或表扫描的查询,不会出现此问题NDB桌子有文本列。

      例如,考虑表格T.定义如下创建表声明:

      创建表t (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT NOT NULL, c INT NOT NULL, d TEXT, INDEX i(b), UNIQUE KEY u(c)) ENGINE = NDB,

      以下查询T.导致共享读取锁定,因为它使用唯一的键查找:

      选择*从t其中c = 1;

      但是,此处显示的四个查询中都不会导致共享读取锁:

      选择*从t其中b = 1;选择*从其中d ='1';选择*来自t;选择b,c其中a = 1;

      这是因为,在这四个查询中,第一个使用索引扫描,第二个和第三个使用表扫描,而第四个虽然使用主键查找,但没有检索任何值文本列。

      您可以通过避免使用唯一键查找来检索的查询来帮助最小化共享读取锁的问题文本列,或者在无法避免此类查询的情况下,通过在之后尽快提交事务。

  • 回滚。没有部分交易,也没有部分回滚交易。重复的键或类似错误会导致整个事务回滚。

    这种行为与其他事务存储引擎的不同之处不同InnoDB这可能会回滚单个语句。

  • 事务和内存使用率。正如本章其他地方所指出的,NDB Cluster不能很好地处理大型事务;比起尝试一个包含大量操作的大事务,最好是执行多个每个操作都只有少量操作的小事务。在其他考虑因素中,大型事务需要非常大的内存量。因此,许多MySQL语句的事务行为会受到影响,如下表所示:

    • 截断表在使用时不是交易NDB表。如果一个截断表如果清空表失败,则必须重新运行该表,直到成功为止。

    • 删除(即使没有在哪里条款)事务性的。对于包含大量行的表,您可能会发现使用多个行可以提高性能删除从…限制……语句删除操作。如果您的目标是清空桌子,那么您可能希望使用截断表反而。

    • 加载数据语句。加载数据在使用时不是交易NDB表。

      重要的

      当执行一个加载数据声明,这是NDBEngine以不定期的时间间隔执行提交,以便更好地利用通信网络。不可能提前知道此类提交何时发生。

    • ALTER TABLE and transactions。复制A.NDB表作为一个部分改变表,副本的创建是非事务性的。(在任何情况下,该操作将在删除副本时回滚。)

  • 事务和COUNT()函数。使用NDB群集复制时,无法保证事务一致性COUNT ()副本的功能。换句话说,当对源执行一系列语句(插入删除(或两者都是),在执行的单个事务中更改表中的行数选择count(*)来自表格对副本的查询可能产生中间结果。这是由于选择计数(…)可能执行脏读,而不是在NDB存储引擎。(参见Bug #31321了解更多信息。)