Comments 18
Мне очень интересны транзакции
Долгое время в какой-то мере успешно боремся с Lock и Deadlock в многопоточных highload скриптах, работающих с InnoDB — уверен, что можно бороться эффективнее)
Долгое время в какой-то мере успешно боремся с Lock и Deadlock в многопоточных highload скриптах, работающих с InnoDB — уверен, что можно бороться эффективнее)
Обязательно напишу, только это будет, наверное, после нового года.
Если возможно, попробуйте упростить транзакции. Если нет, то попробуйте сделать структуру таблиц такую, что SELECT и UPDATE будут обращаться к разным таблицам, в основном.
А можно с этого места и поподробнее?
Блокировки возникают чаще всего из-за того, что тот, кто читает ждет того, кто пишет. Причем в Innodb это на уровне строк. Бывает, что некоторые колонки в таблице часто обновляются, но редко читаются. Самый типичный пример UPDATE news SET viewcount = viewcount+1 WHERE id=987; В этом примере достаточно перенести статистику просмотров в другую таблицу и на таблице news почти не останется апдейтов, что дает выйгрыш (и эффективное использование кэша). Если хотите подробнее, опишите конкретную ситуацию на форуме SQLinfo.ru.
В InnoDB все проще. Вступает в силу механизм транзакций и версионность.
Чтение в большинстве случаев и не блокируется. Просто во время чтения вы и не увидите изменений, вызванных текущими транзакциями. Просто будете читать старую версию.
В мане все описано неплохо InnoDB and TRANSACTION ISOLATION LEVEL + Consistent Non-Locking Read.
Чтение в большинстве случаев и не блокируется. Просто во время чтения вы и не увидите изменений, вызванных текущими транзакциями. Просто будете читать старую версию.
В мане все описано неплохо InnoDB and TRANSACTION ISOLATION LEVEL + Consistent Non-Locking Read.
Все будет так, если одни транзакции только пишут, а другие — только читают. Если транзакция считывает данные (возможно не одну строку, а информацию, основанную на многих строках таблицы, не идентифицируемых по первичному ключу), а потом выполняет запись, то в зависимости от уровня изоляции блокировка будет при записи или при выполнении COMMIT.
Если Вы действительно занимаетесь хайлоад проектами, то данная статья вам должна быть абсолютно бесполезной, т.к. LOCK TABLES это самое большое зло, которое и врагу не пожелаешь, и если вы его используете где-то, вам стоит многое в жизни переосмыслить
Возможно, еще было бы неплохо снабдить примерами эту статью, ну и следующие тоже, чтобы можно было запустить у себя и протестировать.
А, вообще, спасибо :)
А, вообще, спасибо :)
Собственно замечания к статье.
Описание механизма LOCK TABLES это конечно круто, но кому это реально нужно?
Если уже писать статью о блокировках, то нужно писать их в контексте транзакций и 4х степеней изоляции транзакций, в контексте InnoDB чтаблиц с их MVCC, по крайней мере объяснить почему в MyISAM есть только убогий LOCK TABLE и сразу сказать почему его не стоит использовать особенно в веб приложениях.
LOCK TABLE часто используется в нетранзакционных сторидж енжинах для создания псевдо-транзакций, т.к. он реализован на уровне сервера, а не на уровне сторидж енжина. Я даже видел как некоторые использовали LOCK TABLE для InnoDB!!!
В общем то, о чем реально нужно было писать
SELECT… LOCK IN SHARE MODE
SELECT… FOR UPDATE
в транзакциях
Описание механизма LOCK TABLES это конечно круто, но кому это реально нужно?
Если уже писать статью о блокировках, то нужно писать их в контексте транзакций и 4х степеней изоляции транзакций, в контексте InnoDB чтаблиц с их MVCC, по крайней мере объяснить почему в MyISAM есть только убогий LOCK TABLE и сразу сказать почему его не стоит использовать особенно в веб приложениях.
LOCK TABLE часто используется в нетранзакционных сторидж енжинах для создания псевдо-транзакций, т.к. он реализован на уровне сервера, а не на уровне сторидж енжина. Я даже видел как некоторые использовали LOCK TABLE для InnoDB!!!
В общем то, о чем реально нужно было писать
SELECT… LOCK IN SHARE MODE
SELECT… FOR UPDATE
в транзакциях
Спасибо за ценный комментарий.
Вообще-то в черновом варианте даже написал про FOR UPDATE и LOCK IN SHARE MODE, но потом решил что в отрыве от InnoDB, а соответственно и транзакций с их уровнями изоляций это будет не в тему. Всё-таки эта статья предназначена для новичков, чтобы было понимание, что такое блокировки и с чем их едят, а уже потом можно рассматривать особенности различных механизмов хранения.
Вообще-то в черновом варианте даже написал про FOR UPDATE и LOCK IN SHARE MODE, но потом решил что в отрыве от InnoDB, а соответственно и транзакций с их уровнями изоляций это будет не в тему. Всё-таки эта статья предназначена для новичков, чтобы было понимание, что такое блокировки и с чем их едят, а уже потом можно рассматривать особенности различных механизмов хранения.
сегодня читал про блокировку файлов в пхп при работе с ними, и сразу задался вопросом «А есть ли что-то подобное в МуСКУЛе?».
спасибо=) в мемориз=)
спасибо=) в мемориз=)
Если вы читали про блокировки файлов в пхп, то вам стоит почитать про блокировки в SQLight там это действительно тоже LOCK на файловом уровне, а в MySQL есть средства гораздо более грамотной блокировки.
Кому интересно…
Блокировка файлов (в php & perl) на запись реализована наподобие «LOW_PRIORITY WRITE», т.е. читающие процессы пропускаются вперёд. Хотя это можно и предотвратить путём некоторого механизма блокировки дополнительных файлов, но обычно это требуется, если «читателей» на порядок больше «писателей» при большой интенсивности чтения-записи.
Блокировка файлов (в php & perl) на запись реализована наподобие «LOW_PRIORITY WRITE», т.е. читающие процессы пропускаются вперёд. Хотя это можно и предотвратить путём некоторого механизма блокировки дополнительных файлов, но обычно это требуется, если «читателей» на порядок больше «писателей» при большой интенсивности чтения-записи.
Спасибо. Теперь я понял, почему INSERT DELAYED отсутствует, да и вообще не нужен в InnoDB (=
Столкнулся с проблемой поиска причин длительных блокировок (у меня InnoDB)
Почерпнул информацию из этой статьи:
www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/
Если вкратце:
mysql не показывает, какие блокировки установлены на данный момент (возможно в будущих версиях появятся инструменты для этого, или уже появились, но я о них не знаю).
Однако, косвенно можно оценить, кто запросил блокировку, командой SHOW ENGINE INNODB STATUS (лучше SHOW ENGINE INNODB STATUS \G, чтобы было более читаемо)
В выводе есть список транзакций, и если какая-то из них висит долгое время, то можно предположить, что в этой транзакции и кроется проблема, там же будет id mysql-потока, который можно искать в show processlist и в бинлогах.
Почерпнул информацию из этой статьи:
www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/
Если вкратце:
mysql не показывает, какие блокировки установлены на данный момент (возможно в будущих версиях появятся инструменты для этого, или уже появились, но я о них не знаю).
Однако, косвенно можно оценить, кто запросил блокировку, командой SHOW ENGINE INNODB STATUS (лучше SHOW ENGINE INNODB STATUS \G, чтобы было более читаемо)
В выводе есть список транзакций, и если какая-то из них висит долгое время, то можно предположить, что в этой транзакции и кроется проблема, там же будет id mysql-потока, который можно искать в show processlist и в бинлогах.
Sign up to leave a comment.
Блокировки в MySQL