1. Against creating *scratch tables*: Running DDL statements in production can screw you up a big time. And anyhow my doing a create table won’t be transaction safe if it is MyISAM and if InnoDB, I will be messing up with the common tablespace which I don’t want to do in production. This puts me into a trade-off of saving data in replication and risk of losing everything one bad morning.

2. Against row based replication: My last resort is row based replication that goes against the very first reason of using temporary tables. Most of us use temporary tables (there are more reasons also) because we want to replace multiple inserts with one bulk in the main table. Now if I enable RBR, I go back to stone age as far as my slaves are concerned.

I’m in a complete deadlock situation of Reliability vs Performance. And to top it all, I want both.

For example, if you create a table with 1 column:
CREATE TABLE `test`.`ints` (id int(1));

And your procedure looks like this:
START TRANSACTION;
INSERT INTO `test`.`ints` VALUES (1);
CREATE TEMPORARY TABLE…
…
COMMIT;

… then the temporary table will be created inside the transaction.

I’ve never looked at the internals, but if you just issue START TRANSACTION; COMMIT; with nothing in between, nothing shows up in the binlog. I’m assuming then there is a list of “events” that can occur that cause a transaction to start in the binlog. It seems to me right now that this is simply a case of “create temporary table” is left out of this set of events. I suspect that the word temporary has nothing to do with it… that a simple “CREATE TABLE” does not cause a transaction to start, but that “CREATE TABLE AS SELECT” does.

I logged a bug – #37011

You can completely disregard the previous post because I just figured out that the real difference is the “CREATE TEMPORARY TABLE … AS SELECT” syntax. If I take that out and try to make a normal temporary table, it puts the table creation _before_ the transaction starts.

The plot thickens… you can do the following, and everything will be inside the transaction:

START TRANSACTION;
CREATE TEMPORARY TABLE `test`.`test2` AS SELECT 1;
CREATE TEMPORARY TABLE `test`.`temporary_table`
( `id` int(11) NOT NULL,
`value_1` varchar(10) default NULL,
`value_2` varchar(10) default NULL,
`value_3` varchar(10) default NULL
) ENGINE=InnoDB;

Note that I am using a stored procedure and that I have my code surrounded by START TRANSACTION; COMMIT;

mysql> SHOW binlog events IN ‘bin-logs.000440′\G
*************************** 1. row ***************************
Log_name: bin-logs.000440
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 98
Info: Server ver: 5.0.27-standard-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: bin-logs.000440
Pos: 98
Event_type: Query
Server_id: 1
End_log_pos: 224
Info: use `test`; DROP TEMPORARY TABLE IF EXISTS `test`.`temporary_table`
*************************** 3. row ***************************
Log_name: bin-logs.000440
Pos: 224
Event_type: Query
Server_id: 1
End_log_pos: 300
Info: use `test`; BEGIN
*************************** 4. row ***************************
Log_name: bin-logs.000440
Pos: 300
Event_type: Query
Server_id: 1
End_log_pos: 272
Info: use `test`; CREATE TEMPORARY TABLE `test`.`temporary_table`
ENGINE = InnoDB
AS SELECT id,
value_1,
value_2,
value_3
FROM `test`.`permanent_table`

I was including a drop temporary table statement because if this worked, I was going to create a process that could potentially run this multiple times per session. Interestingly enough, we don’t care if the drop table statement isn’t rolled back in a crash – because a crash would drop the tmp table anyway.

Then I decided to check a new version, so I ran this in 5.1.24-rc and I got the same results.

So at first glance, we suspect that its a bug where the very first temporary table transaction is not included. I ran several additional tests, and I can’t really find any consistency. If I create two temp tables, the BEGIN occurs between the two, however if I do create temp table, drop temp table, create temp table, the BEGIN occurs before the last create.

See http://dev.mysql.com/doc/refman/5.1/en/innodb-implicit-commit.html , http://dev.mysql.com/doc/refman/5.1/en/innodb-error-handling.html and http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html .

But there’s a slim chance that it’ll get better in the future – see http://www.scribd.com/doc/2575733/The-future-of-MySQL-The-Project .