所以，我们正在尝试运行一个报告进入屏幕，它不会更改任何存储的数据。但是，它很复杂，因此需要通过几个 (TEMPORARY*) 表。
它从复制的活动表中提取数据。
从
temp_PreCalc
并从实时数据中填充它们以创建下一个 (TEMPORARY*) 表输出
有效地导致：
INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc JOIN live_Tab1 ON ... JOIN live_Tab2 ON ... JOIN live_Tab3 ON ...
该报告不是一个“确定”的答案，期望它只是一个“快照”报告，一旦出现在屏幕上就会过时。
没有顺序或可重复性问题。
因此，理想情况下，我会将我的 TRANSACTION ISOLATION LEVEL 降低到 READ COMMITTED... 但是，我不能因为 live_Tab1,2,3 是使用 BIN_LOG STATEMENT 类型复制的...
该语句既可爱又快速-几乎不需要任何时间来运行，因此资源负载现在比以前少（它进行了单独的选择和插入）但它等待（据我所知）因为等待的 SELECT用于在 live_Tab 上的可重复/可同步锁定，以便可以安全地复制任何结果。事实上，由于等待，现在需要更多时间。
我想看到响应时间的性能优势！
除了将数据写入 (TEMPORARY*) 表然后丢弃。
没有 live_ 表目的地 - 只有来源......
- 这些表实际上不是临时表，而是动态创建和丢弃的 InnoDB 表，因为报告计算需要自连接和删除......但它们是临时的
我现在似乎在兜圈子寻找答案。
我没有 SUPER 特权，也不想要它......所以不能为这个连接会话设置 BIN_LOG=0（为什么这是一个要求？）
所以...
如果我有一个临时数据库或表通配符，它将我的所有 temp_“临时”表从复制中排除...（我正在等待此更改在我的主机中心进行）
MySQL 是否允许我
SET Session TRANSACTION ISOLATION LEVEL READ COMMITTED；
INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc JOIN live_Tab1 ON ... JOIN live_Tab2 ON ... JOIN live_Tab3 ON ... ;
或者我还会得到我的
“无法执行语句：无法写入二进制日志，因为 BINLOG_FORMAT = STATEMENT 并且至少一个表使用仅限于基于行的日志记录的存储引擎......”
即使它在技术上不正确？我期待它，因为我认为复制将仅仅因为它看到“INSERT”语句而启动，并且将对涉及复制资格的任何表进行简单检查，即使没有目标实际上是复制有资格的....
还是会给我惊喜？
我真的无法面对使用不愉快的解决方案，比如
选择输出文件加载数据输入文件
事实上，我认为我什至不能使用它 - 我将如何获得唯一的文件名？我将如何清理它们？报告由最终用户直接按需运行，我只有 MySQL 接口访问服务器。
或通过 PHP 客户端流式传输，只是为了将 INSERT 与 SELECT 分开，这样 MySQL 就不会对哪些表符合复制条件感到不安......