Once your data reaches a stable size, or a growing table has increased by tens or some hundreds of megabytes, consider using the 一旦您的数据达到稳定的大小，或增长表增加了几十或几百兆字节，考虑使用OPTIMIZE TABLE statement to reorganize the table and compact any wasted space. OPTIMIZE TABLE语句重新组织表并压缩任何浪费的空间。The reorganized tables require less disk I/O to perform full table scans. 重新组织的表需要更少的磁盘I/O来执行完整的表扫描。This is a straightforward technique that can improve performance when other techniques such as improving index usage or tuning application code are not practical.这是一种简单的技术，可以在其他技术（如提高索引使用率或调整应用程序代码）不实用时提高性能。
OPTIMIZE TABLE copies the data part of the table and rebuilds the indexes. OPTIMIZE TABLE复制表的数据部分并重建索引。The benefits come from improved packing of data within indexes, and reduced fragmentation within the tablespaces and on disk. 好处在于改进了索引中的数据打包，减少了表空间和磁盘上的碎片。The benefits vary depending on the data in each table. 根据每个表中的数据，好处各不相同。You may find that there are significant gains for some and not for others, or that the gains decrease over time until you next optimize the table. 你可能会发现，有些人有显著的收益，而另一些人没有，或者收益会随着时间的推移而减少，直到你下一次优化表格。This operation can be slow if the table is large or if the indexes being rebuilt do not fit into the buffer pool. 如果表很大，或者正在重建的索引不适合缓冲池，则此操作可能会很慢。The first run after adding a lot of data to a table is often much slower than later runs.向表中添加大量数据后的第一次运行通常比以后的运行慢得多。
In 在InnoDB, having a long PRIMARY KEY (either a single column with a lengthy value, or several columns that form a long composite value) wastes a lot of disk space. InnoDB中，拥有一个长主键（要么是一个长值的单列，要么是形成长复合值的几列）会浪费大量磁盘空间。The primary key value for a row is duplicated in all the secondary index records that point to the same row. 一行的主键值在指向同一行的所有二级索引记录中重复。(See Section 15.6.2.1, “Clustered and Secondary Indexes”.) （见第15.6.2.1节，“聚集索引和二级索引”。）Create an 如果主键很长，则创建一个自动递增列作为主键，或者为长AUTO_INCREMENT column as the primary key if your primary key is long, or index a prefix of a long VARCHAR column instead of the entire column.VARCHAR列的前缀而不是整个列建立索引。
Use the 使用VARCHAR data type instead of CHAR to store variable-length strings or for columns with many NULL values. VARCHAR数据类型而不是CHAR来存储可变长度的字符串或具有许多空值的列。A CHAR( column always takes N)N characters to store data, even if the string is shorter or its value is NULL. CHAR(N)列始终使用N个字符来存储数据，即使字符串较短或其值为空。Smaller tables fit better in the buffer pool and reduce disk I/O.较小的表更适合缓冲池，并减少磁盘I/O。
When using 当使用COMPACT row format (the default InnoDB format) and variable-length character sets, such as utf8 or sjis, CHAR( columns occupy a variable amount of space, but still at least N)N bytes.COMPACT的行格式（默认的InnoDB格式）和可变长度字符集（如utf8或sjis）时，CHAR(N)列占用可变的空间量，但仍然至少占用N个字节。
For tables that are big, or contain lots of repetitive text or numeric data, consider using 对于大的表，或者包含大量重复的文本或数字数据，考虑使用COMPRESSED row format. COMPRESSED行格式。Less disk I/O is required to bring data into the buffer pool, or to perform full table scans. 将数据带入缓冲池或执行完整表扫描所需的磁盘I/O更少。Before making a permanent decision, measure the amount of compression you can achieve by using 在做出永久性决定之前，请测量使用COMPRESSED versus COMPACT row format.COMPRESSED行格式和COMPACT行格式可以实现的压缩量。