mysqld.log中出现以下警告：[警告]由于BINLOG_FORMAT = STATEMENT，因此使用statement 格式将不安全的语句写入二进制日志。该语句不安全
，因为它使用了LIMIT子句。这是不安全的，因为无法预测其中包含的行集。
我想将复制格式切换为
MIXED。 但是根据MySQL文档：
当存在任何临时表时，不建议在运行时切换复制格式，因为存在临时表。使用基于语句的复制时仅记录
，而使用基于行的复制时不记录。
因此，问题是如何识别是否是否有任何临时表可以安全地切换二进制日志格式？
#1 楼
由于执行此操作时二进制日志将具有特定格式，因此尽管MySQL（eh Oracle [仍然无法摆脱我的口舌]）建立了此功能，您仍可以决定不一起使用这两种格式。要在没有mysql重新启动的情况下完全安全地播放，请尝试以下操作：
FLUSH TABLES WITH READ LOCK;
FLUSH LOGS;
SET GLOBAL binlog_format = 'MIXED';
FLUSH LOGS;
UNLOCK TABLES;
这将以“ MIXED”格式保留最后一个binlog。倒数第二个（紧随其后的）二进制日志的存在只是关闭了以前格式的最后一个二进制日志。一旦执行
FLUSH LOGS;，第一个UNLOCK TABLES;之前的所有现有会话都将开始写入最后一个二进制日志。 试一试!!!
CAVEAT
在应得的信用额度上给予信用，我的回答确实是@带@Jonathan的回答。我只是关闭并打开二进制日志。
UPDATE 2011-10-12 13:58 EDT
如果他对一个主动的大师这样做，他将得到+1。从该主服务器复制更多的从服务器，您还需要担心中继日志也采用新格式。您可以执行以下操作：
在从属服务器上运行
STOP SLAVE; 在主服务器上运行以下命令：
FLUSH TABLES WITH READ LOCK;
FLUSH LOGS;
SET GLOBAL binlog_format = 'MIXED';
FLUSH LOGS;
UNLOCK TABLES;
/>在从属服务器上，运行
START SLAVE; 运行
STOP SLAVE;和START SLAVE;旋转中继日志，并导致新条目被复制为任何格式。您可能还希望在从站中应用binlog_format更改。评论
要记住的一件事是，mysql复制设置实际上是基于每个客户端会话设置的。设置全局binlog_format只会更改NEW会话的值。因此，如果您在持久连接客户端的系统上运行它，则即使您按此处指定的方法进行刷新和锁定，对设置所做的任何更改也不会立即生效-这些更改直到客户端生效重新连接（或在他们自己的会话中设置值，但以我的经验，前者更有可能）。
–奥斯丁米尔斯
13年3月21日在21:32
对于那些好奇的人，您还可以将这个“ binlog_format ='MIXED';”进入您的my.cnf。
–基督徒
13年4月6日在0:27
仅供参考，此答案与此处的答案不一致：dba.stackexchange.com/questions/58539/…
– HTTP500
2014-2-10 13:42
手册指出：这意味着更改复制主服务器上的日志记录格式不会导致从属服务器更改其匹配的日志记录格式。 （.snip ..）在复制过程中更改主日志上的二进制日志记录格式，或者在从属数据库上也未更改二进制日志格式，可能会导致意外结果，甚至导致复制完全失败。
–半个高加索
2014年9月22日在7:44
@Halfgaar就在上周，我将奴隶从MIXED切换到STATEMENT了三次，没有任何不良影响。我这样做是因为复制由于竞争条件而中断。执行查询之前，该表在从属服务器上不存在。因此，我切换到STATEMENT来保持稳定。当然，在我这样做的同时，所有写操作都停止了。顺便说一句，我也做了大师。
– RolandoMySQLDBA
2014-09-22 11:29
#2 楼
要在运行时切换binlog_format，您可以：set global binlog_format = 'MIXED';
这会将所有新会话设置为混合binlog格式。所有现有会话将一直使用以前设置的方式，直到它们结束。
您也可以手动执行
set session binlog_format = 'MIXED';以专门解决会话中的任何问题。评论
我不问方法，我问最安全的方法，以及如何检查是否存在任何临时表。
– Quanta
2011-09-27 14:42
最安全的方法是先设置全局变量，然后等待其余会话结束。
–乔纳森
2011-09-27 15:39
评论
快速警告。从RBR-> SBR并使用已提交读内容时，请当心：bugs.mysql.com/bug.php?id=62493