OPTIMIZE rebuilds the table. This (for InnoDB) squeezes out some of the fragmentation and wasted space. This is unlikely to make a noticeable difference in any query.
Also, OPTIMIZE does an ANALYZE. This has a chance of changing the statistics, thereby leading to a different (better or worse) EXPLAIN plan.
Since ANALYZE is much faster (on InnoDB) than OPTIMIZE, just do the ANALYZE.
Various non-ANALYZE actions cause an ANALYZE to be done.
ANALYZE randomly probes the BTrees, gathering stats. Sometimes the resulting stats are poor. There is effectively no way to prevent this from happening. Several partial hacks have been created over the years; 5.6.7 gets close to eliminating this problem with ANALYZE. Here's one of them: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_stats_persistent_sample_pages
Ok,
Here a sample of config to setup your replication :
On Master in your my.cnf add :
server-id = 1
log-bin = /database/bin-log/mysql-bin
binlog_cache_size = 16M
slave_compressed_protocol = 1
binlog_format = MIXED
max_binlog_size = 100M
On your slave in my.cnf add :
server-id = 2
relay-log-space-limit = 50G
relay-log = /database/relay-log/relay-bin
relay-log-index = /database/relay-log/relay-bin.index
skip-slave-start
read_only = 1
Now you have two solutions, dump or binary copy.
In both case you should made your transformation (myisam to InnoDB) on your slave slave and switch your slave to master. Also you should active binlogs to catch the master position.
First solution, you can make a dump of your master ( with the master-data option to catch master position) On your .sql dump file, search and replace ENGINE=myisam to InnoDB and load thé dump to thé slave server. You have all tables on InnoDB engine :) after started réplication and catching up your the late : "second behind master= 0 " it´s time to switch slave to master ( with a new dump (now from slave to master) and take care to switch the conf also).
The second solution is the same but with a cold backup, stop mysql, copy datadir (4gb Will probably done in ~ 10mins dépends on your solution : scp, usb keys...) start your slave and alter each table with engine=innodb. Like thé first one, when it´s done, you should switch master/slave and alter ex-master tables.
Caution with "alter table engine=InnoDB"
Mysql Will create a InnoDB table and copy data in it so your table size is tablesize x 2 (when innodb table is dobe, mysql drop myisam table)
I'm on my phone so sorry if there are many strange word... :)
(I didn't detailed replication set up cause it's not the subject but we let me know if you want some help.)
Best Answer
No, you should not do
OPTIMIZE TABLE
because it is the same asThus, doing an
ALTER TABLE tblname ... ;
of any kind followed by
OPTIMIZE TABLE tblname;` would create two temp tables.BTW when you do
OPTIMIZE TABLE tblname;
on an InnoDB Table you get thisSo, never use
OPTIMIZE TABLE
. You could runANALYZE TABLE tblname;
instead.Changing datatypes of columns ? If and only if there is the possibility of value truncation, you could run
ANALYZE TABLE tblname;
during off-hours.Dropping Indexes ? No need to since dropping an index remove all index stats for that index, leaving other indexes alone.