Тупиковые ситуации могут возникнуть, если у вас есть два или более независимых запроса, одновременно обращающихся к одним и тем же ресурсам (таблицам / строкам). Пример из реального мира:
На двух машинах работают два механика. В какой-то момент во время ремонта им обоим понадобятся отвертка и молоток, чтобы открутить какую-то сильно застрявшую деталь. Механик А хватает отвертку, механик Б хватает молоток, и теперь никто из них не может продолжить, поскольку второй инструмент, который им нужен, недоступен: они заблокированы.
Теперь люди умны, и один из механиков будет любезным и передаст свой инструмент другому: оба могут продолжать работать. Базы данных несколько глупы, и ни один запрос не будет любезным и разблокирует любой ресурс, вызывающий тупик. На этом этапе СУБД включит Рэмбо и принудительно откатит (или просто убьет) один или несколько взаимно заблокированных запросов. Это позволит продолжить выполнение одного удачного запроса и продолжить получение необходимых ему блокировок / транзакций, и, надеюсь, у прерванных запросов есть достаточно умные приложения, обрабатывающие их, которые позже снова перезапустят транзакции. На старых / более простых СУБД вся система зависала до тех пор, пока администратор базы данных не зашел и не произвел некоторую ручную очистку.
Существует множество способов справиться с тупиками и, в первую очередь, их избежать. Один из важных моментов - никогда не блокировать ресурсы в «случайном» порядке. В случае с нашими механиками оба должны сначала потянуться за отверткой, а затем за молотком. Таким образом, один может успешно работать немедленно, а другой будет знать, что ему нужно ждать.
Что касается смешивания InnodB / MyISAM - MySQL полностью поддерживает смешивание / сопоставление типов таблиц в запросах. Вы можете выбрать / присоединиться / обновить / вставить / удалить / изменить в любом порядке, просто помните, что выполнение каких-либо действий с таблицей MyISAM в рамках транзакции InnoDB НЕ сделает MyISAM волшебным образом осведомленным о транзакции. Части MyISAM будут выполняться / фиксироваться немедленно, и если вы откатите сторону InnoDB, MyISAM также не откатится.
Единственная основная причина придерживаться MyISAM в наши дни - это поддержка полнотекстового индексирования. Помимо этого, InnoDB, как правило, будет лучшим выбором, поскольку он имеет полную поддержку транзакций и блокировку на уровне строк.
person
Marc B
schedule
18.10.2010
COUNT(*)s. MyISAM НЕ быстрее InnoDB, и InnoDB не быстрее MyISAM. Один работает лучше в одном случае, другой - в другом. Я фактически перешел на InnoDB, потому что он был более производительным для таблиц с большим количеством операций записи, потому что он использовал блокировку на уровне строк вместо блокировки на уровне таблиц MyISAM. Итак, если вам не нужна какая-либо специфическая функция MyISAM, не бойтесь переключаться;) - person NikiC schedule 18.10.2010