Оптимизировать запрос на ОБНОВЛЕНИЕ MySQL

#mysql

#mysql

Вопрос:

Я пытаюсь выполнить этот запрос, и обновляемая таблица содержит около 10 000 строк. Выполнение запроса занимает так много времени, что я даже не могу дождаться возврата.

Через пару часов в этой таблице будет 100 000 строк, и это займет в 10 раз больше времени, чем сейчас. У кого-нибудь есть идеи по его оптимизации?

 UPDATE

`wpsapi4`.`product_details` AS `pd`,
`r2r`.`partmaster` AS `pm`,
`r2r`.`partpriceinv` AS `ppi`,
`r2r`.`manufacturer` AS `m`

SET

`pd`.`product_name`=`pm`.`ItemName`,
`pd`.`data_source`='R2R',
`pd`.`partmaster`=`pm`.`id`,
`pd`.`pu`=``.`ppi`.`DistributorPartNumberShort`,
`pd`.`description_raw`=`pm`.`ItemDescription`,
`pd`.`dealer_price`=`ppi`.`MSRP`,
`pd`.`weight`=`pm`.`Weight`,
`pd`.`vendor_name`=`m`.`ManufacturerName`

WHERE

(
`pm`.`ManufacturerNumberShort`=`pd`.`vendor_number`
OR
`pm`.`ManufacturerNumberLong`=`pd`.`vendor_number`
)
AND
`pm`.`id`=`ppi`.`DistributorPartNumberShort`
AND
`ppi`.`DistributorID`=2
AND
`pm`.`ManufacturerID`=`m`.`id`
  

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

Комментарии:

1. По-моему, это много подсказок.

2. Вы можете оптимизировать инструкции update так же, как вы оптимизируете инструкцию select . Запустите explain для того же запроса с теми же объединениями таблиц и предложением where, чтобы увидеть, что происходит.

3. @JamWaffles: Да, мне нравятся мои тики :), люди говорят мне не использовать их, но я их игнорирую. Я помню, когда я впервые начал работать в mysql, и у меня продолжали возникать ошибки, потому что я использовал зарезервированные слова, так что теперь я везде возвращаюсь назад. это помогает, если я хочу выполнить поиск / замену

4. Верно. Лично я думаю, что они довольно запутанные, но все зависит от личных предпочтений. Я еще не сталкивался с необходимостью использовать зарезервированные слова в качестве имен полей, но я могу это сделать в будущем!

Ответ №1:

Столбцы для индексации — это те, на которые ссылается ваше предложение where.

Рассмотрите возможность добавления следующего:

  1. Индекс в столбце pm.ManufacturerNumberShort.
  2. Индекс в столбце pm.ManufacturerNumberLong.
  3. Индекс на pm.id колонна.
  4. Индекс в столбце pm.ManufacturerID.
  5. Индекс в столбце ppi.DistributorPartNumberShort.
  6. Индекс в столбце ppi.DistributorID.

На основе входных данных от Darhazer:

Рассмотрите возможность добавления одного или нескольких из следующих:

  1. Индекс на pm.ManufacturerNumberShort, pm.id , и столбцы pm.ManufacturerID.
  2. Индекс на pm.ManufacturerNumberLong, pm.id , и столбцы pm.ManufacturerID.
  3. Индекс в столбцах ppi.DistributorPartNumberShort и ppi.DistributorID.

Комментарии:

1. Одиночные индексы работают не так быстро, как составные (следует использовать index_merge или выбрать один из индексов для разрешения предложения where), и в случае обновления каждый индекс увеличивает время, необходимое для записи.

Ответ №2:

Вы выполняете OR по номеру поставщика, я бы начал с того, что убедился, что у вас есть индекс по номеру поставщика в обеих таблицах.

Мне кажется, что другие столбцы уже должны иметь индексы.

Комментарии:

1. @lcarus: Да, спасибо, на самом деле таблицы из базы данных с именем r2r уже полностью оптимизированы, везде индексы. В данный момент я работаю над этой таблицей product_details, и я вижу некоторые нестандартные типы полей, которые могут замедлять работу. В нем есть такие вещи, как varchar (500) и т. Д., Я даже не думал, что это возможно, лол