这两个问题都是之前曾经在生产环境遇到过的，在MySQL5.7里都被很好的解决掉了。简单的记录下；
Q1:
对于prepare statement，总是需要生成完整的SQL，而生成的主要目的是为了复制 （即时你的复制模式为ROW模式！！！）
大概是2012年的下半年，接到一个线上的case，有业务用prepare statement导入数据非常缓慢，导入的方式类似于insert into tbname values (?)….(?)。。。大量的”?”。业务方发现这种批量插入的方式奇慢无比，完全无法满足业务的需要。
从perf 输出我们看到，bmove_upp 的占比非常高，进而根据其调用栈发现卡在Prepared_statement::setup_set_params
具体的不细说了，测试数据和当时我为了绕过这个问题写的一个小patch，可以阅读这个bug report：http://bugs.mysql.com/bug.php?id=67676
修复的方式也很简单，就是对于ROW模式，不再为prepared statement组建SQL.
TIPS: 在5.7里bmove_upp函数已经被移除了，改而使用memmove (Rev:5943)
5.7.2的change log：
Performance of prepared DML statements containing ? parameter substitution markers was improved under row-based logging format: Since the binary log in this case need not include the statement text, and since the statement will not be forced to statement-based logging as some DDL statements might be, there is no need to substitute ? markers to produce a statement suitable for logging. (Bug #67676, Bug #16038776)
官方Patch：Rev:5360, 和我的fix基本类似
Q2:
使用union all来聚合多个SELECT的结果时，需要创建临时表；但这种行为在使用UNION ALL时，是没有必要的，因为建立临时表的目的是为了去重，而根据UNION ALL的语义是无需这么做的。
这是我第一次在线上遇到这个问题，业务方使用大约20个union all来进行数据导出，导致实例的IO直接hang死，经过半天的排查，才定位到原因，年少无知的俺在Facebook上感慨了下，就有人指出这已经是个老Bug了….o(╯□╰)o
Discuss on Facebook：
Bug连接：http://bugs.mysql.com/bug.php?id=50674
该Bug在最近的MySQL5.7.3中被fix掉，真可谓举世欢庆啊, Percona的Peter还专门撰文提到这个问题…
根据change log的描述，满足如下条件的union将无需创建临时表(参考函数st_select_lex_unit::union_needs_tmp_table)：
* The union is UNION ALL, not UNION or UNION DISTINCT.
* There is no global ORDER BY clause.
* The union is not the top-level query block of an {INSERT | REPLACE}
… SELECT … statement.
总的来说，在fix该bug后，以后可以放心的使用UNION ALL了。
