Reputation: 23808
I wanted to read some data from a table in the read-only mode.
Having worked on DB2 earlier, I got confused and tried to use the FOR READONLY clause with my SELECT statement :P
After tinkering with it, I realized the following statement works:
SELECT * FROM dbo.Users READONLY
It took less than half the time to run the query with the READONLY clause than without it.
So I decided to google for some documentation about the same, but I couldn't find any documentation of using READONLY with the SELECT clause.
Our DBA has asked us not to use the READONLY clause if there is no documentation, as it can get obsolete in the newer updates/ versions.
I'd appreciate if someone can point to some useful documentation and let me know if this can be safely used in SQL Server stored procs.
I am using SQL Server version 11.0.3000.0
Upvotes: 5
Views: 51298
Reputation: 1
See the HINTS you can use here https://learn.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-table?view=sql-server-ver16
The NOLOCK is the "READONLY" you are searching for
Upvotes: -1
Reputation: 1
Updated link:
The link in bumbumpaw's reply is no longer valid. I found this in the IBM Knowledge Center regarding the use of the "FOR READ ONLY" clause when querying against an Informix database.
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.50.0/com.ibm.sqls.doc/ids_sqs_1062.htm
As Jeroen Mostert points out, Microsoft SQL Server does not contain a "READONLY" clause, even though it is a reserved keyword. It does, however, have an option to set the database level to "READ_ONLY", which is outside the scope of this question.
Upvotes: -1
Reputation: 28779
Old question, but it deserves a new answer in case someone thinks they've stumbled on a magic go-faster switch.
This has the same semantics as SELECT * FROM dbo.Users PLEASE_BUFF_MY_PYLONS
, and SELECT * FROM Users AS U
. It assigns the alias READONLY
to the table Users
and has no effect whatsoever on execution plans or query execution time on its own, and anyone stating otherwise better have some damn good evidence to back it up (as in, an execution plan that does not show READONLY
is just an alias). READONLY
is a T-SQL keyword, but only in the context of passing table variables to stored procedures. In the context of this query, it's just another identifier.
There are various reasons why a query can be slower in one case, faster in another (cached execution plans are one big reason); aliasing your table to the name READONLY
is not one of them.
While there's no such thing as "readonly" mode for a query, there is such a thing as reading from a table without blocking writers by using snapshot isolation. This is not a magic go-faster switch either, but it is useful in many OLTP workloads.
Upvotes: 15
Reputation: 16137
This is a sample script to highlight what the READONLY
means in the context you used it:
DECLARE @t TABLE(id INT);
INSERT INTO @t(id)VALUES(1),(2),(3);
SELECT READONLY.id FROM @t READONLY;
Resulting in:
id
1
2
3
In other words, you assigned an alias named READONLY
to the table dbo.users
(in the sample, to the table variable @t
).
I would advise against using this as an alias. It may not result in an error, but it can be used in another context in SQL Server (declaring a table valued parameter in a stored procedure). Perhaps READONLY
should have been a reserved keyword for this reason, as it may be confusing to see this word used as a keyword in one case, and as a table alias in another.
Upvotes: 4
Reputation: 2528
Normally, you do not need to include the FOR READ ONLY clause in a SELECT statement. SELECT is a read-only operation by definition, so the FOR READ ONLY clause is usually unnecessary. In certain circumstances, however, you must include the FOR READ ONLY keywords in a SELECT statement.
see this article for more information.
Upvotes: -1