InnoDB表優化沒有鎖定表

如果我在一段時間後重新包裝表（ALTER TABLE foo ENGINE = INNODB），或者在大量INSERT/UPDATE之後重新包裝表， /刪除操作。我不知道這是因爲指示等被重建，還是壓縮了表空間或其他東西？InnoDB表優化沒有鎖定表

這令我做的事情像 ALTER TABLE FOO ENGINE = INNODB應該是常規表維護的一部分，然而利用優化或者改變鎖定這是不可接受的表，是有做了一個好辦法一個數據庫服務器（意味着沒有故障轉移到另一個實例）沒有鎖定整個表？

更新：使用Percona的5.5.17-55

更新：SHOW VARIABLES LIKE '％的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      | 
+----------------------------------------+------------------------+

來源

2012-03-29 Jeremy

你正在使用什麼版本的MySQL？ – RolandoMySQLDBA 2012-04-03 17:32:06

更新的問題包括MySQL版本 – Jeremy 2012-04-03 19:52:10

請將此添加到您的問題：SHOW VARIABLES LIKE'innodb％';' – RolandoMySQLDBA 2012-04-03 20:05:00

你不能改變或優化表，而將其鎖定。但是，使用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

來源

2012-04-04 12:51:29

爲了清楚起見，我更新了問題。我會研究pt-online-schema-change，謝謝。 – Jeremy 2012-04-04 15:58:16

正是我在找什麼，謝謝。 – Jeremy 2012-04-05 18:18:54

閱讀文檔，我不會在InnoDB表中使用這個工具（全部使用外鍵）。檢查http://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html#cmdoption-pt-online-schema-change--alter-foreign-keys-method – 2013-11-05 15:32:09

基本上，你正在做一個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://www.mysqlperformanceblog.com/2008/04/23/testing-innodb-barracuda-format-with-compression/

來源

2012-04-04 11:57:55 capi

使用新文件格式或行壓縮是否有缺點？ – Jeremy 2012-04-04 15:59:35

CPU使用率應該有小幅增加，但是我所見過的所有測試都表明沒有負面影響。舊格式「Antelope」保留爲默認值，主要用於與舊版MySQL兼容。新的Barracuda文件格式很可能成爲下一個主要MySQL版本的默認文件格式。 – capi 2012-04-05 12:12:54

根據我的經驗，啓用壓縮行格式只有在您的平均行長足夠大的情況下才有意義（使用SHOW TABLE STATUS LIKE'table_name''來檢查），並且至少有一個文本字段含有較長的內容。 – 2015-07-20 17:02:19

從MySQL 5.6.17，MySQL的默認支持InnoDB表的在線優化。

來源

2014-03-29 12:32:12 Aadant

InnoDB表優化沒有鎖定表

回答

相關問題