В моей базе данных (MySQL) периодически возникают таймауты блокировки. У меня пока нет основной причины, и у нас пока нет рекомендаций. Раньше мне пришлось бы переиндексировать свои индексы SQL Server и Oracle, потому что они в этом нуждались. Никто и никогда не говорит об этом и MySQL.
Есть рекомендации?
Как уже отмечалось, выбранный механизм хранения является основным фактором, влияющим на производительность MySQL. Если вы используете MyISAM или InnoDB, это зависит от вашей рабочей нагрузки.
Если в вашем случае операции SELECT выполняются быстро и не так много операций записи в БД, MyISAM совсем не плох. Но если у вас есть даже умеренная активность записи и некоторые длительные операции SELECT, имейте в виду, что MyISAM поддерживает только блокировки на уровне таблицы. Во время медленного SELECT все операции записи будут помещены в очередь, что довольно скоро может привести ко всем видам неприятных проблем.
InnoDB поддерживает блокировки на уровне строк, транзакции и многоверсионность, поэтому даже сильно смешанные операции чтения / записи не замедлят его почти так же, как MyISAM.
Также убедитесь, что какой бы механизм хранения ни использовался, он правильно настроен. Для MyISAM key_buffer_size и table_cache являются наиболее важными значениями для настройки, для InnoDB первое, что нужно настроить, это innodb_buffer_pool_size.
Но у обоих механизмов хранения есть свои недостатки: например, только MyISAM поддерживает полнотекстовую индексацию, а табличное пространство InnoDB не сжимается, поэтому в активно обновляемой таблице, где происходит много удалений / обновлений / вставок, вам необходимо выгружать содержимое таблицы и время от времени всасывать их обратно.
Вам не нужно повторно индексировать MySQL, за исключением случаев повреждения в результате сбоя или внезапного отключения питания. Если у вас возникли проблемы с блокировкой, вы можете захотеть преобразовать свои таблицы MyISAM (или, по крайней мере, таблицы с наибольшими проблемами конфликтов блокировки) в InnoDB. Для этого требуется немного больше ОЗУ, но он поддерживает блокировку на уровне строк, а не только на уровне таблицы (среди многих других улучшений).
Вам также может потребоваться запустить команду «показать полный список процессов»; чтобы убедиться, что это не что-то явно явно блокирующее таблицу, например, какое-то резервное копирование.
Таймаут блокировки? MySQL очень хорошо разработан в этом отношении, особенно если вы используете движок InnoDB.
Индексы не нужно повторно индексировать ... но они должны быть правильно индексированный в первую очередь.
Если мы говорим о фактических блокировках, таких как тупик / тайм-аут, вы должны проверить наличие подозрительных LOCK TABLES команда.
Похоже на проблемы со статистикой индекса.
Если вы используете MyISAM, внезапные всплески INSERT могут отбросить статистику в глазах оптимизатора запросов MySQL. Это приведет к тому, что оптимизатор запросов MySQL будет делать очень неверные предположения в планах EXPLAIN запросов SELECT.
Если вы используете InnoDB, ANALYZE TABLE становится совершенно бесполезным.
Пока таблица достаточно мала, ANALYZE TABLE - это все, что вы действительно можете сделать для MyISAM. Восстановление индексов может периодически помогать таблицам InnoDB.
До тех пор, пока таблицы не будут сильно написаны, статистика индекса останется стабильной, а планы запросов EXPLAIN останутся более согласованными.
Просто помните: как только у вас будет множество INSERT, UPDATE и DELETE, все ставки на достоверную статистику индексов будут отключены до следующего перестроения или ANALYZE TABLE.
Что касается тайм-аутов прерывистой блокировки, вот что нужно учитывать: для SELECT в таблицах InnoDB возможно тайм-аут при тупиках.
Запросы SELECT могут выполнять блокировку gen_clust_index, также известный как кластерный индекс.
Вот три вопроса об обмене стеком для администраторов баз данных, на которые я настойчиво просматривал @RedBlueThing, человек, задавший эти вопросы. @RedBlueThing нашел способ ответить на свои вопросы.
Пожалуйста, прочтите внимательно эти ссылки. Надеюсь, это поможет.
http://dev.mysql.com/doc/refman/5.0/en/myisamchk.html
После сжатия таблицы с помощью myisampack следует использовать myisamchk -rq для восстановления ее индексов.
Но я не знаю, понадобится ли вам это когда-нибудь. Индексы должны обновляться автоматически.
У меня были подобные проблемы, и в «старые времена» Sql Server я бы изменил запросы на Select with NOLOCK ().
Я решил эту проблему в хранимых процедурах MySQL, используя:
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;
-- execute select command here such as (this works in stored procs as well):
SELECT LAST_NAME FROM TEMP WHERE NAME LIKE 'SMITH%' ;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ ;
-Кларк Вера