是否有理由将数据库事务用于只读sql语句？

Question

As the question says, is there ever a reason to wrap read-only sql statements in a transaction? Obviously updates require transactions.

Answer 1

You still need a read-lock on the objects you operate on. You want to have consistent reads, so writing the same records shouldn't be possible while you're reading them...

If you issue several SELECT statements in a single transaction, you will also produce several read-locks.

SQL Server has some good documentation on this (the "read-lock" is called shared lock, there):

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

I'm sure MySQL works in similar ways

Answer 2

Yes, if it's important that the data is consistent across the select statements run. For instance if you were getting the balance of several bank accounts for a user, you wouldn't want the balance values read to be inconsistent. Eg if this happened:

With balance values B1=10 and B2=20

1. Your code reads B1= 10.
2. Transaction TA1 starts on another DB client
3. TA1 writes B1 to 20, B2 to 10
4. TA1 commits
5. Your code reads B2 = 10

So you now think that B1 is 10 and B2 is 10, which could be displayed to the user and that says that $10 has disappeared!

Transactions for reading will prevent this, since we would read B2 as 20 in step 5 (assuming a multiversioning concurrency control DB, which mysql+innodb is).

Answer 3

MySQL 5.1, with the innodb engine has a default transaction isolation level which is REPEATABLE READS. So if you perform your SELECT inside a transaction no Dirty reads or Nonrepeatable reads can happen. That means even with transaction commiting between two of your queries you'll always get a consistent database. In theory in REPEATABLE READS you couls only fear phantom reads , but with innodb this cannot even occurs. So by simply opening a Transaction you can assume database consistency (coherence) and perform as much select as you want without fearing parallel-running-and-ending write transactions.

Do you have any interest in having such a big consistency constraint? Well it depends of what you're doing with your queries. having inconsistent reads means that if one of your query is based on a result from a previous one you may have problems:

• if you're performing only one query you do not care, at all
• if none of your queries assumes a result from a previous one, do not care
• if you never re-read a record in the same session, same thing
• if you always read dependencies of your main record in the same query and do not use lazy loading, no problem
• if a small inconsistency between your first and last query will not break your code, then forget about it. But be careful, this can make a very hard to debug application bug (and hard to reproduce). So get a robust application code, something which could maybe handle databases errors and crash nicely (or not even crash) when this occurs (2 time in one year?).
• if you show critical data (I mean bank accounts and not blogs or chats), then you should maybe care about it
• if you have a lot of write operations , then you increase the risk of inconsistent reads, you may need to add transactions at least on some key points
• you may need to test impact on performances , having all read requests in transactions, when several write transactions are really altering the data, is certainly slowing the engine, he needs to handle several versions of the data. So you shoul dcheck if the impact is not too big for your application