读完了High.Performance.MySQL_Second.Edition的第一章，这是读原版书最顺畅的一次，可能是有些基础的关系，很多其实语法很复杂的语句也能理解其意思。不过在第一章中还是碰到一个问题，也许是读得太顺的缘故，容不得半点的瑕疵吧。
Table Conversions
There are several ways to convert a table from one storage engine to another, each
with advantages and disadvantages. In the following sections, we cover three of the
most common ways.
ALTER TABLE
The easiest way to move a table from one engine to another is with an ALTER TABLE
statement. The following command converts mytable to Falcon:
mysql> ALTER TABLE mytable ENGINE = Falcon;
This syntax works for all storage engines, but there’s a catch: it can take a lot of time.
MySQL will perform a row-by-row copy of your old table into a new table. During
that time, you’ll probably be using all of the server’s disk I/O capacity, and the origi-
nal table will be read-locked while the conversion runs. So, take care before trying
this technique on a busy table. Instead, you can use one of the methods discussed
next, which involve making a copy of the table first.
When you convert from one storage engine to another, any storage engine-specific
features are lost. For example, if you convert an InnoDB table to MyISAM and back
again, you will lose any foreign keys originally defined on the InnoDB table.
Dump and import
To gain more control over the conversion process, you might choose to first dump
the table to a text file using the mysqldump utility. Once you’ve dumped the table,
you can simply edit the dump file to adjust the CREATE TABLE statement it contains. Be
sure to change the table name as well as its type, because you can’t have two tables
with the same name in the same database even if they are of different types—and
mysqldump defaults to writing a DROP TABLE command before the CREATE TABLE, so you
might lose your data if you are not careful!
See Chapter 11 for more advice on dumping and reloading data efficiently.
CREATE and SELECT
The third conversion technique is a compromise between the first mechanism’s
speed and the safety of the second. Rather than dumping the entire table or convert-
ing it all at once, create the new table and use MySQL’s INSERT … SELECT syntax to
populate it, as follows:
mysql> CREATE TABLE innodb_table LIKE myisam_table;
mysql> ALTER TABLE innodb_table ENGINE=InnoDB;
mysql> INSERT INTO innodb_table SELECT * FROM myisam_table;
That works well if you don’t have much data, but if you do, it’s often more efficient
to populate the table incrementally, committing the transaction between each chunk
so the undo logs don’t grow huge. Assuming that id is the primary key, run this
query repeatedly (using larger values of x and y each time) until you’ve copied all the
data to the new table:
mysql> START TRANSACTION;
mysql> INSERT INTO innodb_table SELECT * FROM myisam_table
-> WHERE id BETWEEN x AND y;
mysql> COMMIT;
After doing so, you’ll be left with the original table, which you can drop when you’re
done with it, and the new table, which is now fully populated. Be careful to lock the
original table if needed to prevent getting an inconsistent copy of the data!
这是第一章的最后一小节内容，主要讲存储引擎的转换方法，其中列举了三种方法及其优缺点，个人感觉第三种和第一种是一样的，他怎么会说是介于第一种和第二种之间的呢？
后面说如果采用第三种方法碰到数据量大的时候应该根据主键切分成更小的处理单位，以防止undo logs变得很大，也能提高效率。如果说第三种方法是因为可以用分段处理从而显得和第一种不同的话那还说的过去。
还要说一下，这里说到的分段处理的方法是个好方法，很多地方都能用到，大型的数据库系统有时候需要处理一些大数据量的变动时如果一起操作可能会导致系统一段时间内的繁忙，客户端长时间没有响应，甚至拒绝连接。根据聚集索引分段的处理倒是能很好的解决这个问题，一小块一小块的处理不会造成一段时间的繁忙，用户几乎感觉不到(当然这取决于切分的粒度)。之前也知道这种类型的方法，但是对于原因没有那么了解，现在知道了-undo logs.