SELECT занимает слишком много времени

Мне нужна ваша помощь :)SELECT занимает слишком много времени

У меня есть таблица в базе данных (SQL Server 2008 R2). В настоящее время существует около 4 миллионов строк.

Потребительские приложения берут строки оттуда (блокируют их и обрабатывают).

Для защиты строк от уловления более чем одного потребителя я запирающего его, добавив некоторые флаг в соответствующем столбце ...

Таким образом, чтобы «запереть» запись я

SELECT TOP 1 .....

а затем UPDATE операция с записью с определенным идентификатором.

Эта операция занимает до 5 секунд сейчас (я пробовал в SQL Server Management Studio):

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

Как я могу ускорить его?

Вот структура таблицы:

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);

источник

2012-02-25 Jeffrey Rasmussen

не делать '' выбрать *, его быстрее явно перечислить столбцы, даже если вы хотите, чтобы все из них. –

@ Muad'Dib, в то время как я согласен на 100% с настроением и блогами и часто говорю об этом (например, http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/10/bad-habits-to-kick -using-select-omitting-the-column-list.aspx), разница в скорости - если вам действительно нужны все столбцы - настолько минимальна, что она не существует для всех целей и задач. Этот аргумент похож на то, что падение капли воды на вашем капот повлияет на аэродинамику и приведет к ухудшению газового пробега.В то время как академически верно, трудно доказать (и многое, намного сложнее оправдать выход и вытирать его). –

@Aaron Я полностью согласен с очевидными исключениями из большого столбца BLOB/CLOB/XML/etc, который будет болотовать соединение, но не нужен –

Индексы должны быть размещены на любых столбцов, которые вы используете в ИНЕКЕ вашего запроса. Поэтому вам следует добавить индекс в recordLockedBy.

Если вы не знаете, о индексы выглядят here

источник

2012-02-25 17:59:26

Спасибо! Я просто добавил индекс в этот столбец. Нужно ли мне как-то обновлять данные таблицы, чтобы увидеть индекс в работе? Теперь после создания индекса я не видел более быстрых результатов. –

Quicker стартер для вас:

ALTER TABLE myTable 
    ADD INDEX IDX_myTable_recordLockedBy (recordLockedBy)

источник

2012-02-25 18:04:25 Paddy

ли ваш запрос на выборку заявление по идентификатору, а? Если это так, это должно быть установлено как первичный ключ с кластеризованным индексом (по умолчанию для ПК, которые, как я полагаю). Затем SQL сможет перейти непосредственно к записи - должен быть близок к мгновенному. Без этого он будет выполнять сканирование таблицы, просматривая каждую запись в последовательности, которую они отображают на диске, пока не найдет тот, который вам нужен.

источник

2012-02-25 18:06:22

Я считаю, что столбцы «Identity» являются первичным ключом. –

Я не уверен, что они есть. В этой статье вики говорится, что они не http://en.wikipedia.org/wiki/Identity_column. Возможно, я ошибаюсь. –

@Ash в то время как столбцы IDENTITY * могут * быть первичным ключом, и часто это корреляция, но не причинность. Совершенно возможно иметь столбец IDENTITY, который не является первичным ключом, первичным ключом, который не является кластеризованным, первичный ключ, который кластер, но находится в столбце (столбцах), отличном от столбца IDENTITY, или столбце IDENTITY, который имеет кластеризованный индекс, но не является первичным ключом. –

Это не помешает условию гонки на столе и позволит одной и той же строке обрабатывать несколько потребителей.

Посмотрите на UPDLOCK и READPAST запирающих намеков обрабатывать этот случай:

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

источник

2012-02-25 18:07:38 Joe

-1

Если таблица используется для планирования и обработки заданий, может быть, вы можете использовать MSMQ, чтобы решить эту проблему. Вам не нужно беспокоиться о блокировке и тому подобном. Он также значительно масштабируется на предприятии и имеет много разных режимов отправки/приема.

Вы можете узнать больше об этом здесь: http://msdn.microsoft.com/en-us/library/windows/desktop/ms711472(v=vs.85).aspx

источник

2012-02-25 20:43:37 Hovhannes

Вряд ли относится к вопросу, не так ли? –

SELECT занимает слишком много времени

ответ

Смежные вопросы