В MySQL функция NOT EXISTS намного дороже, чем UNION? - PullRequest
1 голос
/ 17 августа 2011

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

INSERT INTO A (SELECT * FROM B)

, а затем во второй раз

INSERT INTO A
SELECT * FROM C
WHERE NOT EXISTS (SELECT * FROM A Where A.field = C.field)

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

Спасибо!!

Ответы [ 2 ]

1 голос
/ 17 августа 2011

Объединение, вероятно, дешевле.Но как обычно с базами данных, это зависит .

Почему?

Потому что то, что вы делаете прямо сейчас, это:

  1. Сканирование таблицыB и вставьте в A.
  2. Сканируйте таблицу C и вставьте в A (там, где ее нет).
  3. Сканируйте таблицу D и вставьте в A (там, где ее нет).

С объединением вы будете делать это:

  1. Таблица сканирования B.
  2. Таблица сканирования C.
  3. Таблица сканирования D.
  4. Вставьте уникальные значения в таблицу A.

Т.е. ваши текущие запросы дважды сканируют таблицы B, C, D и таблицу A плюс накладные расходы для трех отдельных запросов.Запрос на объединение сканировал бы таблицы B, C, D и сортировал строки (чтобы получить уникальные значения), а затем вставлял их в таблицу A. На первый взгляд кажется, что объединение будет быстрее, потому что вы выполняете на два меньше сканирования итолько одна вставка (и, следовательно, меньше блокировки).

Что я имею в виду под , зависит :

Индексы: правильно проиндексированы, поиск может бытьбыстрее, чем сортировка данных из B, C и D.

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

0 голосов
/ 17 августа 2011

Возможно, вы захотите взглянуть на INSERT IGNORE ... также, если у вас есть подходящее ограничение UNIQUE KEY в таблице назначения.

Еще одна идея ... Хотя понятия о различиях в производительности нет, вероятно, зависит от структуры таблиц, индексов и данных. Я просто оценил бы различные методы сам и выбрал бы наиболее подходящий.

...