Проблема с производительностью DB2

Мне нужно выполнить запрос к нескольким миллионам записей, сравнивая SSN в одной таблице с производным SSN (я получаю его из более длинного идентификатора, в котором SSN хранится как первые девять символов в этом столбце) в другой таблице. В TABLE1 SSN хранится в виде десятичного числа (9,0). В TABLE2 SSN хранится как char(23). Я запускаю выборку, которая захватывает первые 9 символов, используя этот запрос, который также проверяет, являются ли первые 9 символов числовыми:

LENGTH(RTRIM(TRANSLATE(left(ee.award_id,9), '', '0123456789'))) = 0

DB2 ZOS9 не позволяет мне напрямую преобразовать char в десятичное число, а это означает, что мне нужно преобразовать свой char в varchar, а затем в десятичное число (9,0), чтобы сравнить его с SSN в TABLE1.

Мой вопрос: лучше ли

  1. дважды приведите мой SSn, полученный из символа, в varchar, а затем в десятичное число и сравните с десятичным SSN в TABLE1 или

      cast (cast(left(ee.award_id,9) as varchar(9))as decimal(9,0))

  2. лучше ли преобразовать мой десятичный SSN в varchar и мой производный SSN char в varchar, а затем сравнить два или

  3. два одинаковых по производительности?

Спасибо.


db2 zos
person Serge    schedule 03.04.2014    source источник
comment
Вероятно, было бы быстрее преобразовать десятичный столбец в символ, а затем сравнить его с (первыми 9 символами) столбцом char (у SSN есть начальные 0?). Я удивлен, что вы не можете просто применить его — в документации он указан как приводимый. Есть ли у вас возможность изменить определения таблиц? Ни один из ваших текущих столбцов не идеален - SSN на самом деле не являются числовыми (они представляют собой строку цифровых символов, хотя их следует хранить в неформатированном виде), а хранение ключей, состоящих из нескольких частей, проблематично.   -  person Clockwork-Muse    schedule 03.04.2014
comment
Думаю, лучший способ ответить на этот вопрос — попробовать оба метода и сравнить их производительность.   -  person mustaccio    schedule 03.04.2014
comment
К сожалению, я не могу изменить определения таблиц. Пробовать их оба также не вариант, после первого запуска данные уже будут заполнены, и второй запуск не понадобится.   -  person Serge    schedule 03.04.2014
comment
Если TABLE1.SSN находится в индексе и этот индекс может использоваться в этом случае, то использование функции в поле и последующее сравнение может означать, что такой индекс больше не используется. Если индекс не рассматривается, то я сомневаюсь, что производительность будет сильно различаться, поскольку операция, скорее всего, будет связана с вводом-выводом, а не с процессором.   -  person Darius X.    schedule 03.04.2014

Ответы (1)


arrow_upward
1
arrow_downward

DB2 чрезвычайно быстро выполняет функции. Не тратьте время на его оптимизацию. Вы потенциально можете перевести свои операции со стадии 2 на стадию 1, выбрав правильный предикат, но я не думаю, что это сэкономит вам достаточно ЦП/времени, чтобы быть стоящим.

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

Главное, что вы можете сделать для повышения производительности в этом сценарии, — попытаться проиндексировать сравнение SSN.

В зависимости от того, какую версию вы используете, вы можете добавить «индекс выражения» в функцию, чтобы получить SSN, полученный из CHAR (23), до 9 цифр, с которыми вы хотите сравнить. если вы можете это сделать, возможно, стоит добавить индекс, выполнить запрос, а затем удалить индекс.

Вы также не указали, есть ли у вас какие-либо ограничения производительности/времени. Без каких-либо ограничений, я не вижу причин вообще пытаться его оптимизировать.

person Josh Hull    schedule 14.04.2014