Tips for using temporary tables in mysql Replication

We know that temporary tables have the following features:
1. At the SESSION level, a SESSION is automatically dropped once it is disconnected.
2. It depends on the default engine. If the default engine is INNODB, And you are crazy about using temporary tables. Then, your IBDATA will be infinitely increased.
3. Like the disk table, the data is written to the binlog by default, and the rollback plan is passively added.

Fantasy scenarios:
The database is damaged and there is no backup. The binary logs are all well preserved and happy. Import binary logs to MYSQL.

There are two methods:
1) mysqlbinlog... *. log | mysql dbname; this method uses pipelines to directly restore data, which takes a short time and is highly efficient. However, if there are a bunch of temporary tables in the middle of the log, the Import fails. (Remember the features of the temporary table .)
2) mysqlbinlog ..... *. log> result. log; mysql dbname <result. log; this is a long time, low efficiency, high disk space occupation, and a waste of system resources. However, the import is successful.

If there are a large number of temporary table applications, the correct method should be adopted in master-slave replication: (as I mentioned in the past 08 years .)
When writing data, of course, only the host is used here. Whether you are managing MYSQL in an application or using a client, you should do the following:Copy codeThe Code is as follows: [SQL]
SET SQL _LOG_BIN = 0;
Disable SESSION-level replication.
Update tmp_t1, tmp_t2 set ....;
Drop tmp_t1;
Drop tmp_t2;
SET SQL _LOG_BIN = 1;

Enable SESSION-level replication.