Практическое ограничение на положение "где в" - PullRequest
Новая
       6

Практическое ограничение на положение "где в"

3 голосов
/ 07 июля 2011

У меня довольно простая таблица с примерно миллионами строк.

id  |  my_col  |  other1  |  other 2 | ...

В этой таблице содержится около 15 000 различных значений my_col, и у меня есть индекс для my_col.У меня есть набор из 7k значений my_col, которые мне нужно удалить из этой таблицы.

Что более эффективно делать в SQL (в настоящее время я работаю с MySQL, но в будущем могу портировать на MS SQL).

Это а) В моем коде Java-приложения пропустите все значения my_col и вызовите sql delete для каждого из них. 

for (String my_colValue : listMyCol) {
   [delete from my_table where my_col = my_colValue]
}

или b) Создайте один SQL [большой] оператор, содержащий все эти значения с использованием предложения "где в"? 

delete from my_table where my_col in ('aaa', 'aab', 'aac', ...)

Я бы предположил, что это б), но я не уверен, если указать около 7k значений в этом "где в"предложение становится неэффективным.

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

Ответы [ 3 ]

2 голосов
/ 07 июля 2011

в) Создайте заново свою таблицу.

Вы собираетесь удалить половину своих строк, так что подумайте об этом.В то время как a) и b) могут длиться вечно, воссоздание вашей таблицы будет сложным, но незамедлительным.

И вам нужно загрузить значения 7k во временные таблицы, тогда это просто: 

CREATE TABLE newMyTable
AS
SELECT myTable.*
FROM myTable
    INNER JOIN myValues
        ON myTable.my_col = myValues.my_col

Или, если вы не можете создать таблицу, возможно, это будет достаточно быстро: 

DELETE FROM myTable t
WHERE EXISTS
(
    SELECT *
    FROM myValues v
    WHERE t.my_col = v.my_col
)

Но единственное, что вам нужно иметь в виду: вы должны создать таблицу со своими значениями 7k.

2 голосов
/ 07 июля 2011

Реальный практический предел использования WHERE IN - это насколько велик вы можете сделать свой SQL-запрос. Это определяется переменной конфигурации MySQL max_packet_size. Все остальное - просто компромиссы производительности. Чтобы выяснить, что работает быстрее, бенчмаркинг по-прежнему работает лучше всего.

1 голос
/ 07 июля 2011

Я бы выбрал первый вариант, но все сделаю внутри транзакции.Таким образом, фиксация наступит в конце, а не после каждого оператора DELETE.

Индексы становятся неэффективными при поиске многих записей.

...