Comments 18
Мне очень интересны транзакции
Долгое время в какой-то мере успешно боремся с Lock и Deadlock в многопоточных highload скриптах, работающих с InnoDB — уверен, что можно бороться эффективнее)
Долгое время в какой-то мере успешно боремся с Lock и Deadlock в многопоточных highload скриптах, работающих с InnoDB — уверен, что можно бороться эффективнее)
+5
Обязательно напишу, только это будет, наверное, после нового года.
+2
Если возможно, попробуйте упростить транзакции. Если нет, то попробуйте сделать структуру таблиц такую, что SELECT и UPDATE будут обращаться к разным таблицам, в основном.
+1
А можно с этого места и поподробнее?
+2
Блокировки возникают чаще всего из-за того, что тот, кто читает ждет того, кто пишет. Причем в Innodb это на уровне строк. Бывает, что некоторые колонки в таблице часто обновляются, но редко читаются. Самый типичный пример UPDATE news SET viewcount = viewcount+1 WHERE id=987; В этом примере достаточно перенести статистику просмотров в другую таблицу и на таблице news почти не останется апдейтов, что дает выйгрыш (и эффективное использование кэша). Если хотите подробнее, опишите конкретную ситуацию на форуме SQLinfo.ru.
+1
В InnoDB все проще. Вступает в силу механизм транзакций и версионность.
Чтение в большинстве случаев и не блокируется. Просто во время чтения вы и не увидите изменений, вызванных текущими транзакциями. Просто будете читать старую версию.
В мане все описано неплохо InnoDB and TRANSACTION ISOLATION LEVEL + Consistent Non-Locking Read.
Чтение в большинстве случаев и не блокируется. Просто во время чтения вы и не увидите изменений, вызванных текущими транзакциями. Просто будете читать старую версию.
В мане все описано неплохо InnoDB and TRANSACTION ISOLATION LEVEL + Consistent Non-Locking Read.
0
Все будет так, если одни транзакции только пишут, а другие — только читают. Если транзакция считывает данные (возможно не одну строку, а информацию, основанную на многих строках таблицы, не идентифицируемых по первичному ключу), а потом выполняет запись, то в зависимости от уровня изоляции блокировка будет при записи или при выполнении COMMIT.
0
Если Вы действительно занимаетесь хайлоад проектами, то данная статья вам должна быть абсолютно бесполезной, т.к. LOCK TABLES это самое большое зло, которое и врагу не пожелаешь, и если вы его используете где-то, вам стоит многое в жизни переосмыслить
+1
Возможно, еще было бы неплохо снабдить примерами эту статью, ну и следующие тоже, чтобы можно было запустить у себя и протестировать.
А, вообще, спасибо :)
А, вообще, спасибо :)
+2
Собственно замечания к статье.
Описание механизма 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
в транзакциях
+3
Спасибо за ценный комментарий.
Вообще-то в черновом варианте даже написал про FOR UPDATE и LOCK IN SHARE MODE, но потом решил что в отрыве от InnoDB, а соответственно и транзакций с их уровнями изоляций это будет не в тему. Всё-таки эта статья предназначена для новичков, чтобы было понимание, что такое блокировки и с чем их едят, а уже потом можно рассматривать особенности различных механизмов хранения.
Вообще-то в черновом варианте даже написал про FOR UPDATE и LOCK IN SHARE MODE, но потом решил что в отрыве от InnoDB, а соответственно и транзакций с их уровнями изоляций это будет не в тему. Всё-таки эта статья предназначена для новичков, чтобы было понимание, что такое блокировки и с чем их едят, а уже потом можно рассматривать особенности различных механизмов хранения.
+2
сегодня читал про блокировку файлов в пхп при работе с ними, и сразу задался вопросом «А есть ли что-то подобное в МуСКУЛе?».
спасибо=) в мемориз=)
спасибо=) в мемориз=)
+1
Если вы читали про блокировки файлов в пхп, то вам стоит почитать про блокировки в SQLight там это действительно тоже LOCK на файловом уровне, а в MySQL есть средства гораздо более грамотной блокировки.
+1
Кому интересно…
Блокировка файлов (в php & perl) на запись реализована наподобие «LOW_PRIORITY WRITE», т.е. читающие процессы пропускаются вперёд. Хотя это можно и предотвратить путём некоторого механизма блокировки дополнительных файлов, но обычно это требуется, если «читателей» на порядок больше «писателей» при большой интенсивности чтения-записи.
Блокировка файлов (в php & perl) на запись реализована наподобие «LOW_PRIORITY WRITE», т.е. читающие процессы пропускаются вперёд. Хотя это можно и предотвратить путём некоторого механизма блокировки дополнительных файлов, но обычно это требуется, если «читателей» на порядок больше «писателей» при большой интенсивности чтения-записи.
0
Спасибо. Теперь я понял, почему INSERT DELAYED отсутствует, да и вообще не нужен в InnoDB (=
0
Столкнулся с проблемой поиска причин длительных блокировок (у меня 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 и в бинлогах.
0
Sign up to leave a comment.
Articles
Change theme settings
Блокировки в MySQL