如果我在一段时间后重新打包一个表（ALTER TABLE foo ENGINE = INNODB），或者在大量的INSERT / UPDATE / DELETE之后，我注意到了大量的性能提升。我不知道这是因为指标等是重建，还是压缩表空间或其他东西？
让我觉得做喜欢的事情ALTER TABLE foo ENGINE = INNODB应该是例行表维护的一部分，但是使用OPTIMIZE或ALTER锁定表是不可接受的，有一个好方法使用一个数据库服务器（意味着没有故障转移到另一个实例）没有锁定整个表？
更新：使用Percona 5.5.17-55
更新：SHOW VARIABLES喜欢'innodb％';
+----------------------------------------+------------------------+
| Variable_name | Value |
+----------------------------------------+------------------------+
| innodb_adaptive_checkpoint | estimate |
| innodb_adaptive_flushing | OFF |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 8388608 |
| innodb_auto_lru_dump | 120 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_shm_checksum | ON |
| innodb_buffer_pool_shm_key | 0 |
| innodb_buffer_pool_size | 30064771072 |
| innodb_change_buffering | inserts |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_dict_size_limit | 0 |
| innodb_doublewrite | ON |
| innodb_doublewrite_file | |
| innodb_enable_unsafe_group_commit | 0 |
| innodb_expand_import | 0 |
| innodb_extra_rsegments | 0 |
| innodb_extra_undoslots | OFF |
| innodb_fast_checksum | OFF |
| innodb_fast_recovery | OFF |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antelope |
| innodb_file_format_check | Barracuda |
| innodb_file_per_table | ON |
| innodb_flush_log_at_trx_commit | 0 |
| innodb_flush_log_at_trx_commit_session | 3 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | 1 |
| innodb_force_recovery | 0 |
| innodb_ibuf_accel_rate | 100 |
| innodb_ibuf_active_contract | 1 |
| innodb_ibuf_max_size | 15032369152 |
| innodb_io_capacity | 200 |
| innodb_lazy_drop_table | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_block_size | 512 |
| innodb_log_buffer_size | 67108864 |
| innodb_log_file_size | 402653184 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_overwrite_relay_log_info | OFF |
| innodb_page_size | 16384 |
| innodb_pass_corrupt_table | 0 |
| innodb_read_ahead | linear |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_recovery_stats | OFF |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_show_locks_held | 10 |
| innodb_show_verbose_locks | 0 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_auto_update | 1 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON |
| innodb_stats_sample_pages | 8 |
| innodb_stats_update_need_lock | 1 |
| innodb_strict_mode | OFF |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 8 |
| innodb_thread_concurrency_timer_based | OFF |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_purge_thread | 1 |
| innodb_use_sys_malloc | ON |
| innodb_use_sys_stats_table | OFF |
| innodb_version | 1.0.16-12.8 |
| innodb_write_io_threads | 4 |
+----------------------------------------+------------------------+
答案 0 :(得分：26)
如果不锁定表，则无法对表进行更改或优化。但是，使用Percona Toolkit中的pt-online-schema-change工具（免责声明：我的雇主），你可以做到这一点，而且效果很好。要优化表格，只需使用以下内容：
pt-online-schema-change <options> --alter='ENGINE=InnoDB'
http://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html
答案 1 :(得分：12)
从MySQL 5.6.17开始，MySQL默认支持InnoDB表的在线优化。
答案 2 :(得分：1)
基本上，你在桌子上做OPTIMIZE。对于InnoDB表，OPTIMIZE映射到ALTER TABLE。引用Mysql手册：
对于InnoDB表，OPTIMIZE TABLE映射到ALTER TABLE，后者重建表以更新索引统计信息并释放聚簇索引中未使用的空间。
当删除1/2表时，OPTIMIZE之后是一个非常好的主意。
我会提出改善表现的建议。看到您在配置中支持新文件格式BARRACUDA，您应该使用它。启用它非常简单，只需添加my.cnf：
innodb_file_format=Barracuda
重新启动服务器，然后更改表格以使用新的可用ROW_FORMAT = COMPRESSED：
ALTER TABLE x ROW_FORMAT=COMPRESSED;
根据个人经验，当使用压缩行格式时，表格大小减少到一半，这对性能也有显着的积极影响。
有关详细信息，请尝试通过：
http://dev.mysql.com/doc/refman/5.5/en/innodb-compression-usage.html
http://www.mysqlperformanceblog.com/2008/04/23/testing-innodb-barracuda-format-with-compression/