Производительность обновления Innodb

Question

Недавно мы переключили одну из наших таблиц на InnoDB, и теперь мы испытываем очень медленное время выполнения обновления. Обновление, которое занимало 0,010-0,030 секунды, теперь может занять более 70 секунд. Некоторые запросы отброшены, потому что они не могут приобрести блокировку в пределах предела по умолчанию на 50 секунд (я понимаю, что мы можем поднять этот предел).

В данной таблице есть только один индекс, сам первичный ключ, который является средним значением. Таблица имеет около 1 миллиона строк. Все обновление в этом контексте включает в себя одну строку. Обычно 4-5 столбцов из этой строки влияют в каждом запросе.

Текущий my.cnf вставлен ниже. Вы видите что -нибудь, что может привести к плохой производительности обновления для InnoDB?

[mysqld]
set-variable=local-infile=0

datadir=/db/mysql/data
socket=/var/lib/mysql/mysql.sock
#log = /var/log/mysqld.log
log-error = /var/log/mysqld.error.log
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1


skip-locking
key_buffer = 1G
query_cache_size = 256M
thread_cache_size = 128
table_cache = 2048
max_connections = 400
query_cache_limit = 1024M
log_slow_queries = /var/log/mysql-slow.log
long_query_time = 1
skip-bdb
skip-locking
skip-name-resolve

innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=20M
innodb_flush_log_at_trx_commit=2
#innodb_log_file_size=250M
innodb_log_buffer_size=8M
innodb_lock_wait_timeout=50


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

ОБНОВИТЬ:
innodb_log_file_size: 5242880
HASE_INNODB: Да
«Где» пункт всегда выглядит только для одного столбца, который является основным ключом.

Обновление - 26 июля 2012 года:
Мы обновили нашу базу данных до MySQL 5.5. Теперь обновления InnoDB довольно быстрые, менее 0,010 секунд в нашем конкретном случае. И дисперсия довольно низкая. Мое мнение от этого: Innodb следует использовать с реальной осторожностью на MySQL 5.0.

Answer 1

Перспектива № 1

Когда вы обновляете первичный ключ только в InnoDB, существует редкий, но возможный случай, когда кластерный индекс (он же gen_clust_index) может быть заблокирован.

Однажды я ответил на три сообщения от один человек на эту тему

• Проблема расшифровка тупика в журнале статуса InnoDB
• Причины иногда медленных запросов?
• Приведут ли эти два запроса к тупику, если он будет выполнен в последовательности?

Пожалуйста, внимательно прочитайте их. Плакат этих вопросов нашел свой собственный обходной путь, основанный на том, чтобы увидеть блокировка кластерного индекса InnoDB. К сожалению, он не опубликовал, что такое обходной путь.

Кроме того, когда вы видите, что запросы работают медленно, войдите в MySQL и запустите SHOW ENGINE INNODB STATUS\G и начинать искать замки в кластерном индексе.

Перспектива № 2

Я вижу, вы прокомментировали innodb_log_file_size. Анкет У вас есть это на 5 МБ, по умолчанию. С innodb_buffer_pool_size Установлен 1G, Innodb_log_file_size должен быть на 256 м. Нажмите здесь, чтобы установить innodb_log_file_size на 256M.

Перспектива № 3

Я вижу, ты не используешь innodb_file_per_table. Анкет Вы можете использовать его, чтобы сделать обновления таблиц специально для одной таблицы с миллионом рядов. Нажмите здесь, чтобы увидеть, как очистить инфраструктуру InnoDB, чтобы использовать innodb_file_per_table.

Answer 2

1. Вы обновляете значение значения первичного ключа?

2. Являются ли какие -либо из столбцов иностранных ключей к другим таблицам? Поскольку Innodb также обновляет иностранные ключи в той же транзакции через каскад.

3. Можете ли вы увеличить innodb_buffer_pool_size до более чем 1 ГБ, чтобы вся таблица могла соответствовать памяти?

4. Сколько других таблиц в Шмеа - так как могут возникнуть проблемы, изменяющие размер табличного пространства для выполнения обновления

5. Вы можете попробовать использовать innodb_file_per_table, где для каждой таблицы создается файл табличного пространства. После того, как вы измените этот параметр, вам нужно перезапустить сервер, затем создайте свою базу данных заново, чтобы он вступил в силу.