SELECT takes too long

Question

I need your help :)

I have a table in a database (SQL Server 2008 R2). Currently there are around 4M rows.

Consumer apps take rows from there (lock them and process).

To protect rows from being taken by more than one consumer I'm locking it by adding some flag into appropriate column...

So, to "lock" record I do

SELECT TOP 1  .....

and then UPDATE operation on record with some specific ID.

This operation takes up to 5 seconds now (I tried in SQL Server Management Studio):

SELECT TOP 1 * 
FROM testdb.dbo.myTable 
WHERE recordLockedBy is NULL;

How can I speed it up?

Here is the table structure:

CREATE TABLE [dbo].[myTable](
[id] [int] IDENTITY(1,1) NOT NULL,
[num] [varchar](15) NOT NULL,
[date] [datetime] NULL,
[field1] [varchar](150) NULL,
[field2] [varchar](150) NULL,
[field3] [varchar](150) NULL,
[field4] [varchar](150) NULL,
[date2] [datetime] NULL,
[recordLockedBy] [varchar](100) NULL,
[timeLocked] [datetime] NULL,
[field5] [varchar](100) NULL);

Answer 1

Indexes should be placed on any columns you use in your query's where clause. Therefore you should add an index to recordLockedBy .

If you don't know about indexes look here

Answer 2

Quicker starter for you:

ALTER TABLE myTable
    ADD INDEX IDX_myTable_recordLockedBy (recordLockedBy)

Answer 3

Does your select statement query by id as well? If so, this should be set as a primary key with a clustered index (the default for PKs I believe). SQL will then be able to jump directly to the record - should be near instant. Without it will do a table scan looking at every record in the sequence they appear on disk until it finds the one you're after.

Answer 4

This won't prevent a race condition on the table and allow the same row to be processed by multiple consumers.

Look at UPDLOCK and READPAST locking hints to handle this case:

http://www.mssqltips.com/sqlservertip/1257/processing-data-queues-in-sql-server-with-readpast-and-updlock/

Answer 5

If the table is used for job scheduling and processing, perhaps you can use MSMQ to solve this problem. You don't need to worry about locking and things like that. It also scales much better on enterprise, and has many different send/received modes.

You can learn more about it here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms711472(v=vs.85).aspx