| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > innodb select for update |
| Автор: idti 18.8.2011, 14:33 |
| Как select справляется с ситуацией, когда он уже начал работать и базу в процесе работы поступают данные, который по идее в него должны попасть? Отличается ли for update в этом смысле? |
| Автор: solenko 18.8.2011, 17:23 | ||||
Игнорирует
нет http://dev.mysql.com/doc/refman/5.1/en/innodb-locking-reads.html |
| Автор: idti 19.8.2011, 11:04 | ||
Могут ли быть проблемы с таким запросом?
Есть подозрение, что он может не выполниться, при каких-то условиях. |
| Автор: solenko 19.8.2011, 17:38 |
| Не выполниться он может, по идее, либо в случае http://dev.mysql.com/doc/refman/5.1/en/innodb-deadlock-detection.html либо по http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_lock_wait_timeout |
| Автор: idti 19.8.2011, 22:34 |
| Да, ещё, если таблица повреждена. Это всё очевидно. Возможно тут у меня нет проблемы тогда. Спасибо! |
| Автор: Zloxa 22.8.2011, 09:38 | ||
В разных режимах изоляции - по разному.  Если бы речь шла о версионнике, ответ не вызвал бы сомнений. Но маська - блокировочник. И изоляцию транзакций, если я не ошибаюсь, он обеспечит тем, что не позволит вставить/изменить данные, которые могут попасть под критерии отбора до тех пор, пока отбор не отработает полностью. Врядли для описания такого поведения слово "игнорирует" можно назвать подходящим, хотя результаты действий блокирования и игнорирования - схожи. Естесственно, что при read uncommited изоляция обеспечиваться не будет вовсе, и запрос сможет вернуть не согласованный результат в случае, если исходные данные менялись в процессе работы запроса. Я так полагаю for update в этом отношении, ничего не меняет. Данные не смогут быть изменены лишь и толко после того, как они были отобраны, на сам процесс отбора for update влияет врядли. Впрочем, я не эксперт в MySQL и могу ошибаться. |
