У меня есть основная таблица с именем REF_SERVICE_OFFERING, где у меня уже есть 3 миллиона + данных. Теперь я хотел обновить записи 3M в Java в зависимости от определенного условия.
Мы решили создать временную таблицу (в которой записи будут использоваться для обновления основной таблицы) и использовать приведенный ниже запрос для обновления основной таблицы. Во временной таблице будет храниться более 200 тысяч записей:
UPDATE REF_SERVICE_OFFERING SET
PART_PRICE_BILL_TYPE= TEMP.PART_PRICE_BILL_TYPE,
part_price_unit_type=TEMP.part_price_unit_type,
part_price_allowed_units=TEMP.part_price_allowed_units,
part_price_discount=TEMP.part_price_discount,
part_price_source_id=TEMP.part_price_source_id
FROM REF_SERVICE_OFFERING RSO JOIN ref_offer_temp1 TEMP
ON TEMP.RECORD_NUM = RSO.RECORD_NUM
AND TEMP.SO_NAME = RSO.SO_NAME
AND TEMP.SERVICE_CASE_TYPE = RSO.SERVICE_CASE_TYPE
AND TEMP.WORK_ORDER_TYPE = RSO.WORK_ORDER_TYPE
WHERE (RSO.PART_PRICE_BILL_TYPE IS NOT NULL OR TRIM(RSO.PART_PRICE_BILL_TYPE) NOT LIKE '')
AND (RSO.PART_PRICE_EXCP_SOURCE_ID IS NOT NULL OR TRIM(RSO.PART_PRICE_EXCP_SOURCE_ID) NOT LIKE '')
Наша база данных - Postgres 9.6. Но это обновление занимает много времени и никогда не обновляется. Мы также попытались сбросить только 10k записей во временную таблицу, которая будет использоваться для обновления 4L записей.
Мы пытались выполнить команду EXPLAIN и не могли понять, почему.
Любая помощь могла бы быть полезна.
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что ответ будет зависеть от характеристик базы данных, конфигурации и динамических условий, к которым пользователи SO не имеют доступа.
Хорошо, спасибо за информацию. Но я просто хотел проверить, будет ли это хороший подход для обновления таких записей? Как при сбросе во временные таблицы, создании индекса поверх предложений соединения? Я пробовал на Java, используя подготовленный оператор и выполняя массовое обновление. Но на это уходит много времени. Следовательно, пошел с этим подходом.
В принципе, если вы все делаете правильно, это правильный подход. Я разработал аналогичную систему около 4 лет назад, и мы достигли повышения производительности примерно 10: 1 по сравнению с предыдущей системой на основе Java.
В моем первом комментарии, где я набрал "включая отсутствующие или устаревшие индексы", я хотел сказать «отсутствующие индексы или устаревшая статистика».
Понятно, спасибо @JimGarrison
WHERE (RSO.PART_PRICE_BILL_TYPE IS NOT NULL OR TRIM(RSO.PART_PRICE_BILL_TYPE) NOT LIKE '')
Может, вам сюда нужен А ТАКЖЕ?
@joop, спасибо .. пропустил это тоже .. но я удалил все предложение OR, все то же самое .. никогда не заканчивается .. даже когда я пытаюсь обновить 3 записи из 3 миллионов на основе этого .. обновление занимает 5 минут
Мы не можем вам здесь помочь, вам нужно, чтобы ваш администратор баз данных контролировал запрос, чтобы увидеть, на что нужно время. Многое может быть неправильным, включая отсутствующие или устаревшие индексы. Использование
NOT LIKE ''
кажется мне действительно подозрительным. Опять же, только ваш администратор баз данных может предоставить такую поддержку. Спросить случайных незнакомцев в Интернете, которые не видят вашу базу данных, вряд ли приведет к получению полезной информации. Поговорите со своим администратором баз данных.