0

目前我们有一个数据库，其中 STATEMENT bin 日志格式可以正常工作。
现在我们正在添加一个具有自动增量值的新表。
此自动增量列对业务逻辑没有用处。
我们已将此添加为我们的主键的一部分。
这里 offer_expiry_time 是主键的第一部分，因为我们将所有查询都作为基于到期时间范围的范围查询。

假设我们的表格看起来像这样：

创建表 offer_expiry_info  
    offer_expiry_time BIGINT UNSIGNED NOT NULL null,  
    purchase_id INT UNSIGNED auto_increment,
    主键（offer_expiry_time，purchase_id），
    KEY idx_purchase_id (purchase_id)
)引擎 = INNOBB;

现在我们担心的是：

  1. STATEMENT 级别的 bin 日志格式是否适用于此表？（即使我们对跨复制的自动增量列的不同值也很好）。基本上 STATEMENT 级别会起作用吗？

  2. 如果它有效，那么在启动失败的数据库机器时可能会出现什么问题？

  3. 如果 STATEMENT 模式不起作用，那么我们可以单独为该表使用特定（MIXED）复制模式吗？同一个数据库中的其余表可以有STATEMENT模式吗？

  4. 这可能是一个非常愚蠢的问题，因为我不知道 mysql 如何处理复制。是否可以根据查询类型指定复制模式？（对于插入查询执行 ROW 级复制，对于 DELETE 查询执行 STATEMENT 级复制）

    问题 4 是因为我们确实基于基于范围的删除来执行删除，因此如果我们可以对删除查询进行 STATEMENT 复制，将会有更好的性能。

DELETE FROM order_expiry_info WHERE offer_expiry_time "LESS THAN" SOME TIME

由于我们进行批量插入，因此 STATEMENT 级别的复制对我们有很大帮助。
是否可以让具有自动增量列的表具有 STATEMENT 级别的 bin 日志格式？

[已编辑] 此外，我们还有事务隔离级别的另一个问题。
错误：“无法获取错误二进制日志记录。消息：InnoDB 中的事务级别'REA D-UNCOMMITTED'对于二进制日志模式'STATEMENT'是不安全的”

有什么建议会很有帮助吗？

4

1 回答 1

1

是的，这些场景适用于语句二进制日志。

如果您可以访问日志，您将看到在每个语句之前记录了某些值，以确保正确保留时间戳和自动增量值等内容。

多年来，我一直在使用基于语句的复制，在这些领域中没有任何问题。我建议坚持这一点，并且仅在出现可能需要它们的特定性能情况时才考虑基于行或混合复制。

请注意，某些类型的使用对于基于语句的复制是不安全的，但简单的自动增量使用不是其中之一。

于 2012-10-02T06:24:38.083 回答