Frank Bax wrote:
Actually, the option is really --disable-keys. The --opt option is just
a shorthand for several options (including --disable-keys).
There is more as well and refer to the man page for all the details:
http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html
The --opt
Doesn't only do the disable keys but the following as well:
Quote" This option is shorthand; it is the same as specifying
--add-drop-table --add-locks --create-options --disable-keys
--extended-insert --lock-tables --quick --set-charset. It should give
you a fast dump operation and produce a dump file that can be reloaded
into a MySQL server quickly."
One very nice and quicker import is also the extended-insert, use
compress if you do between two servers as well. The dump with lock will
also speed up your dump and locking the table when you insert if you
database is live is also a good thing, etc.
Obviously you use it as you see fit and the options you want, but if you
do want to get the maximum efficiency, you the --opt, not only the
--disable-keys. I offer it as a suggestions, but if you want to help the
users that will do this, let them use the proper feature to do this and
also let them read the mysqldump man page to see what else the may see fit.
The observation was on speed of import and using the --opt instead of
just the --disable-keys will be more efficient, specially if you do have
a lots of entry. Even more you can even speed this more by increasing
the max_allowed_packet in mysql_dump as well as in the mysqld sections,
or your extended-insert will stop in the import mode if your dump is
much bigger then your mysqld setup and you do have many records in tables.
Anyway, there is more then this, but that's not the list do talk about
all of it.
In any case, it would be nice if you do not provide wrong information to
correct proper one. Just my $0.02 worth.
The "the option is really --disable-keys." will not give you the full
benefit, but that's left for the reader.
Your suggestion will only add problem and delay in import on a live
system that may already have data on it and got corrupted data in one
database or table that you need to restore quickly, or worst multiple
table if the mysqlcheck can't fix it.
I don't know about you, but if I restore database from dump, I hell sure
want to start with empty tables and database first.
So, the --opt will also add as well "--add-drop-table --add-locks
--create-options" in your dump making your restore even more painless
and quicker as well.
But again, do it as you see fit. You do not have to do it the way I
suggest by any mean, but don't cut it short for some users that may not
have tested their restore scenario and think what they may do is good
for them and when they will need it, that time, they will be stuck.
Best,
Daniel
