Есть ли причина использовать транзакцию базы данных для операторов SQL, доступных только для чтения?

Question

Как следует из вопроса, есть ли когда-нибудь причина для переноса в транзакцию операторов SQL, доступных только для чтения?Очевидно, обновления требуют транзакций.

Answer 1

Вам все еще нужна блокировка чтения для объектов, с которыми вы работаете. Вы хотите иметь постоянное чтение, поэтому запись одних и тех же записей не должна быть возможной во время чтения ...

Если вы выполните несколько операторов SELECT в одной транзакции, вы также получите несколько блокировок чтения.

В SQL Server есть хорошая документация по этому вопросу («блокировка чтения» называется там общей блокировкой):

http://msdn.microsoft.com/en-us/library/aa213039%28v=sql.80%29.aspx

Я уверен, что MySQL работает аналогичным образом

Answer 2

Да, если важно, чтобы данные были единообразными для всех операторов выбора. Например, если вы получаете баланс нескольких банковских счетов для пользователя, вы не хотите, чтобы считанные значения баланса были непоследовательными. Например, если это произошло:

Со значениями баланса B1 = 10 и B2 = 20

1. Ваш код читается как B1 = 10.
2. Транзакция TA1 запускается на другом клиенте БД
3. TA1 записывает от B1 до 20, от B2 до 10
4. TA1 фиксирует
5. Ваш код читается как B2 = 10

Итак, теперь вы думаете, что B1 равен 10, а B2 равен 10, что может быть отображено пользователю, и это говорит о том, что $ 10 исчезло!

Транзакции для чтения предотвратят это, так как мы будем читать B2 как 20 на шаге 5 (при условии, что DB управления параллельными версиями имеет несколько mysql + innodb).

Answer 3

MySQL 5.1, с механизмом innodb, имеет уровень изоляции транзакции по умолчанию, который является ПОВТОРНЫМИ ЧТЕНИЯМИ.Поэтому, если вы выполняете SELECT внутри транзакции, не может произойти Грязное чтение или Неповторимое чтение .Это означает, что даже при совершении транзакции между двумя вашими запросами вы всегда получите согласованную базу данных.Теоретически в REPEATABLE READS вы можете только бояться фантомное чтение , но с innodb это даже не происходит. Таким образом, просто открыв транзакцию, вы можете принять согласованность базы данных (согласованность) и выполнять столько операций выбора, сколько хотите, не опасаясь параллельных транзакций записи и завершения.

Есть ли у вас какие-либозаинтересованность в таком большом ограничении согласованности?Ну, это зависит от того, что вы делаете со своими запросами.наличие несовместимых чтений означает, что если один из ваших запросов основан на результате предыдущего запроса, у вас могут возникнуть проблемы:

• , если вы выполняете только один запрос, который вас не волнует, вообще
• если ни один из ваших запросов не принимает результат предыдущего, не обращайте внимания
• , если вы никогда не перечитываете запись в одном сеансе, то же самое
• , если вы всегдапрочитайте зависимости вашей основной записи в том же запросе и не используйте отложенную загрузку, нет проблем
• , если небольшое несоответствие между вашим первым и последним запросом не нарушит ваш код, тогда забудьте об этом.Но будьте осторожны, это может сделать очень трудной для отладки ошибку приложения (и трудно воспроизвести).Так что получите надежный код приложения , что-то, что может, возможно, обрабатывать ошибки в базах данных и красиво аварийно (или даже не аварийно), когда это происходит (2 раза в год?).
• , если вы показываете критические данные (я имею в виду банковские счета, а не блоги или чаты), тогда вам, возможно, следует позаботиться об этом
• , если у вас много операций записи , тогда выЧтобы повысить риск несогласованного чтения, вам может потребоваться добавить транзакции хотя бы по некоторым ключевым точкам
• вам может понадобиться проверить влияние на производительность , имея все запросы на чтение в транзакциях, когда несколько записейТранзакции действительно изменяют данные, конечно же, замедляя движок, ему нужно обрабатывать несколько версий данных.Поэтому вы должны проверить, не слишком ли велико воздействие для вашего приложения