Какой была самая крутая оптимизация SQL для медленного запроса?

Question

Просто разговариваю с моим коллегой. По пути к кофеварке он шел с прыжком на своем пути.

Я спросил его, «что с« ройной »прогулкой?», Он ответил: «Я только что сократил двухчасовой запрос до 40 секунд! Это так здорово».

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

Но, в конце концов, он гудел.

Вопрос в том, что за SQL, который запал вам в голову и заставил вас гудеть, оптимизируя медленные запросы?

Answer 1

Я должен сказать, когда я научился создавать и использовать покрытые индексы. Теперь THAT был повышением производительности.

Answer 2

Использование SQL BULKIMPORT для сокращения нескольких часов унаследованного кода INSERT до менее минуты.

Answer 3

Всегда приятно взять плохо написанный, загруженный курсором запрос и исключить курсоры, сократить код вдвое и повысить производительность во много раз.

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

Answer 4

У меня был запрос, который был изначально написан для SQL Server 6.5, который не поддерживал синтаксис объединения SQL 92, т.е.

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

вместо этого было написано как

select foo.baz
from foo, bar
where foo.a *= bar.a

Запрос был некоторое время назад, и соответствующие данные были собраны, чтобы сделать запрос слишком медленным, около 90 секунд для его завершения. К тому времени, когда возникла эта проблема, мы обновились до SQL Server 7.

После осмотра индексов и других пасхальных событий я изменил синтаксис объединения, чтобы он соответствовал SQL 92. Время запроса сократилось до 3 секунд.

Не думаю, что у меня когда-нибудь снова появится такое чувство. Я был офигенным героем.

Answer 5

Раньше я работал над системой CICS / DB2, написанной на языке COBOL. Многие наши запросы выполняли полное (и медленное) сканирование таблиц, хотя у нас были все правильные индексы и предложения WHERE.

Оказалось (и у меня это может быть в прошлом, прошло 15 лет), что проблема заключалась в том, что мы использовали PIC S9(n) COMP в WORKING STORAGE для параметров запроса, но DB2 хотела PIC S9(n) COMP-3. Используя неправильный тип данных, DB2 должна была выполнить полное сканирование таблицы, чтобы преобразовать значения в базе данных в значение, которое мы передавали. Мы изменили наши определения переменных, и запросы теперь могли использовать индексы, что резко улучшили нашу производительность.

Answer 6

Изменение порядка условий внутри предложения WHERE, чтобы оно сначала отфильтровывало наиболее различающее условие (при этом удаляются индексы из недискриминационных столбцов, таких как пол).

Answer 7

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

Answer 8

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

, так как это был мой первый опыт использования sql на встроенном устройстве - он сильно отличался от обычных вещей, связанных с сервером (индексы, нормализации и т. Д.)

--- в том, что касается серверов, индексы являются настоящим благословением. Кроме того, если вы немного постараетесь и избавитесь от как можно большего количества нулей в своей таблице, вы будете удивлены приростом производительности - не многие разработчики фокусируются на нулях, они обычно используют индексы и другие документированные вещи

несколько других менее эксплуатируемых способов - использование xml для обработки нескольких пакетных вставок / обновлений / удалений за 1 ход вместо выполнения 1 вставки за раз - в SQL 2005 это может быть очень круто

Answer 9

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

Теперь, увеличив скорость «реального» кода, который я написал, изменив структуры данных и алгоритмы в классе, вот где я получаю свое ажиотаж (и репутацию профессионала, который исправляет производительность на работе).

Answer 10

(половина темы)

Я переписал хранимую процедуру из 3000 строк в LINQ2SQL / C #. Хранимая процедура манипулировала большим количеством данных между кучей неиндексированных временных таблиц. Версия LINQ2SQL считала данные в пару словарей и ILookups, а затем я вручную соединил данные с простым старым кодом C #.

Хранимая процедура заняла около 20 секунд, а версия LINQ2SQL / C # заняла 0,2 секунды.