Нужна помощь в настройке sql-запроса - PullRequest
4 голосов
/ 25 марта 2010

Мне нужна помощь, чтобы улучшить этот SQL-оператор. Время выполнения составляет около 125 мс.
Во время выполнения моей программы этот sql (лучше: одинаково структурированные sqls для разных таблиц)
будет вызываться 300.000 раз.

Среднее количество строк в таблицах составляет около 10.000.000 строк, и новые строки (обновления / вставки) будут добавляться с отметкой времени каждый день. Данные, которые интересны для этой конкретной экспортной программы, находятся за последние 1-3 дня. Может быть, это полезно для создания индекса. Данные, которые мне нужны, это текущая действительная строка для данного идентификатора и предшественник datarow для получения обновлений (если существует).

Мы используем базу данных Oracle 11g и Dot.Net Framework 3.5

SQL-оператор для повышения:

select 
  ID_SOMETHING,    -- Number(12)
  ID_CONTRIBUTOR,  -- Char(4 Byte)
  DATE_VALID_FROM, -- DATE
  DATE_VALID_TO    -- DATE

from
  TBL_SOMETHING XID

where
  ID_SOMETHING = :ID_SOMETHING
  and ID_CONTRIBUTOR = :ID_CONTRIBUTOR
  and DATE_VALID_FROM <= :EXPORT_DATE
  and DATE_VALID_TO >= :EXPORT_DATE

order by
  DATE_VALID_FROM asc;

Здесь я загрузил текущий План объяснения для этого запроса.

Я не эксперт по базам данных, поэтому я не знаю, какой тип индекса лучше всего подходит для этого требования. Я видел, что есть много различных возможных типов индекса, которые могут быть применены. Возможно, подсказки Oracle Optimizer тоже полезны.

У кого-нибудь есть хорошая идея для настройки этого sql или может указать мне правильное направление?

Ответы [ 3 ]

5 голосов
/ 25 марта 2010

План объяснения выглядит настолько хорошо, насколько это возможно, но это не обязательно много значит. Индекс, предложенный Кассной, - это именно то, что я бы предложил.

В любом случае, выполнение 300000 похожих запросов в вашей программе заставляет меня спросить: это необходимо? Может быть, вы можете достичь той же цели с меньшим количеством запросов, каждый из которых выполняет немного больше.

Если вы не можете избежать такого большого количества запросов, вы должны хотя бы использовать подготовленные операторы. Если вы используете LINQ, это скомпилированные заявления для вас. Таким образом, вы избегаете затрат на синтаксический анализ, которые, вероятно, составляют значительную часть общих расходов, особенно для таких простых запросов.

4 голосов
/ 25 марта 2010

Создать составной индекс:

CREATE INDEX ix_something_s_c_d ON tbl_something (id_something, id_contributor, date_valid_from)

К сожалению, вы ищете константу в диапазоне двух столбцов, а не столбец в диапазоне двух констант, поэтому последнее поле не очень избирательно. Это может помочь в заказе, хотя.

1 голос
/ 25 марта 2010

Вы говорите:

Данные, которые интересны для этого конкретная экспортная программа заключается в последние 1-3 дня.

Значит ли это, что вас интересуют строки, в которых DATE_VALID_FROM находится в течение последних трех дней? Если это так, вы можете получить больше радости от индекса, который выглядит следующим образом:

create index something_idx 
  on tbl_something (date_valid_from, id_something, id_contributor, date_valid_to)
/

Включая date_valid_to означает, что чтение индекса может удовлетворить запрос, не касаясь таблицы вообще. Начиная с date_valid_from, все строки, которые могут вас заинтересовать, помещают в один и тот же фрагмент индексного пространства.

Выше предполагается, что ваши 300 000 звонков для различных значений id_something и id_contributor. Если это предположение неверно - скажем, что они все для одного и того же id_contributor или вы выполняете 50 000 вызовов для одного и того же id_contributor подряд - тогда было бы более разумно вести с (id_contributor, date_valid_from ...). Как обычно бывает при настройке запросов, особенности бизнес-логики имеют решающее значение для достижения успешного результата. Да, и сравнение различных идей имеет важное значение.

Я согласен с AmmoQ, что выполнение одного и того же оператора 300 000 раз в одном процессе звучит как реализация RBAR, которая может больше подходить для подхода, ориентированного на наборы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...