问题:

I don't use Stored procedures very often and was wondering if it made sense to wrap my select queries in a transaction.

My procedure has three simple select queries, two of which use the returned value of the first.

回答1:

In a highly concurrent application it could (theoretically) happen that data you've read in the first select is modified before the other selects are executed.

If that is a situation that could occur in your application you should use a transaction to wrap your selects. Make sure you pick the correct isolation level though, not all transaction types guarantee consistent reads.

Update : You may also find this article on concurrent update/insert solutions (aka upsert) interesting. It puts several common methods of upsert to the test to see what method actually guarantees data is not modified between a select and the next statement. The results are, well, shocking I'd say.

回答2:

Transactions are usually used when you have insert, update or delete statements and you want to have the atomic behavior, that is, either commit every thing or commit nothing. However, you could use transaction for select statements to make sure nobody else could update the table of interest while the bunch of your select queries are executing.

Have a look at this msdn post.