Живий Журнал Миколи Козака
2003-07-08 15:11:15 - SQL
Недавно загорівся спір на рахунок використання швидкодіючих алгоритмів у мові SQL тут. Провів практичні тестування. Мав 2 таблиці: 1-а - 323000 записів (індексована); 2-а - 190000.
Задача ставилася така: знищити записи в таблиці 1, з номерами, яких немає у таблиці 2. Були представлені 3 різні методи:
1.
DELETE Table1
WHERE id NOT IN
(SELECT id FROM Table2)
2.
DELETE Table1
WHERE NOT EXISTS
(SELECT 1 FROM Table2 WHERE Table2.id = Table1.id)
3.
DELETE Table1
WHERE id IN
(SELECT t1.id
FROM Table1 t1
LEFT JOIN Table2 t2 ON t1.id = t2.id
WHERE t2.id IS NULL)
Практика підказувала, що перший варіант найшвидший.
Протестував усі варіанти. Ось результат:
1 варіант: 7 сек. без використання у субзапиті параметра "distinct" і 4 сек. з використанням "distinct".
2 варіант: недочекався результату. Вирубив задачу після 10 хв. очікування.
3 варіант: 9 сек. без використання у субзапиті параметра "distinct" і 6 сек. з використанням "distinct".
Дуже велике значення має індексування поля, по якому робиться зв'язок між таблицями. Не менш важливим є наявність параметра "distinct".
P.S. Перший варіант виявився кращим.
Судячі з того, що у тебе з distinct результати виявилися настільки кращими, випливає, що у тебе були неунікальні значення ID в Table2. Отже, ти не до кінця зрозумів, в чому зміст цієї операції, а твої тести занадто штучні.
andyp
2andyp: В мене унікальність зразу двох полів (у т.ч. ID). Але замітив, що використання "dsitinct" завжди трохи прискорює роботу. На рахунок унікальності ти не ставив задачу. Тести проводив на реальних таблицях (тобто не заповнених даних з "балди").
P.S. Можеш заходити під своїм паролем. Для мене буде краще бачити, хто коментує.
Соррі, забув. :)
"використання "dsitinct" завжди трохи прискорює роботу" — завжди????? Це в якійсь іншій версії матриці, напевно. :)
CopyRight 2018 © Nik Kozak. Version 5.55