mysql的handle_query函数先有prepare然后是optimize函数，但我们stonedb的optimize函数是根据MySQL的st_select_lex_unit::exec()写的，不知道为啥没有正常的optimize流程
两种解决方案：
1、修改抛异常的代码行Query_result_create::prepare (sql_insert.cc:2753)函数
assert(create_table->table == NULL);
2、重写stonedb的st_select_lex_unit::optimize_for_stonedb函数，改动比较大，涉及功能多。
解决方案更新：
A：我们发现，这个问题是由于在优化器的代码中，Lex unit 两次prepare造成的。
首先我们抛弃了对assert语句修改的考虑，因为那里判断表没有创建是合理的。
于是解决方案有两种，
1：考虑在lex unit 的prepare里加入 is_prepared的判断。但这个方案，影响面很大，因为这个函数所有的语法都会影响到。
2：针对，select union 或者 select join，以及他们出现的复杂的组合做修改。发现了三处异常点需要进行is_prepared判断。1：union处。2：join处。3：fake_lex_prepare处。
B：针对我们的修改添加了相应mtr语句进行覆盖。一并记录在issue226中。 https://github.com/stoneatom/stonedb/issues/226
ADD test cases to cover these ctas queries for the following reason.
1: From code perspective. There are enough evidences that we want to support these ctas.
2: Our fix can cover these related queries.
CREATE TABLE t2 AS SELECT LEFT(f1,171) AS f2 FROM t1 UNION SELECT LEFT(f1,171) AS f2 FROM t1;
CREATE TABLE t3 AS SELECT t1.f1 AS f3 FROM t1 LEFT JOIN t2 ON t1.f1 = t2.f2;
CREATE TABLE t4 AS SELECT t1.f1 AS f4 FROM t1 INNER JOIN t2 ON t1.f1 = t2.f2;
CREATE TABLE t5 AS SELECT t1.f1 AS f5 FROM t1 RIGHT JOIN t2 ON t1.f1 = t2.f2;
CREATE TABLE t6 AS SELECT t1.f1 AS f6 FROM t1 UNION SELECT t2.f2 AS f6 FROM t2 LEFT JOIN t3 ON t2.f2 = t3.f3;
CREATE TABLE t7 AS SELECT t1.f1 AS f7 FROM t1 UNION SELECT t2.f2 AS f7 FROM t2 INNER JOIN t3 ON t2.f2 = t3.f3;
CREATE TABLE t8 AS SELECT t1.f1 AS f8 FROM t1 UNION SELECT t2.f2 AS f8 FROM t2 RIGHT JOIN t3 ON t2.f2 = t3.f3;
CREATE TABLE t9 AS SELECT t1.f1 AS f9 FROM t1 INNER JOIN t3 ON t1.f1 = t3.f3 UNION SELECT t2.f2 AS f9 FROM t2;
4、MySQL正常流程堆栈
