чем заменить distinct в sql
Чем заменить distinct в sql
Альтернатива SELECT DISTINCT
Я не слишком хорошо разбираюсь в SQL-запросах, но заметил значительное снижение производительности при выполнении запроса с помощью Select Distinct. Я запускаю SQL Server 2008 R2. Ниже приведен мой запрос:
Кто-нибудь знает, как отредактировать этот запрос, не используя select select, чтобы ускорить запрос, возвращая те же результаты? Любая помощь приветствуется. спасибо.
Вам нужно только DISTINCT из-за JOIN.
Поэтому не используйте JOIN: используйте EXISTS и нажимайте все таблицы, которые вы фактически не выбираете из предложения EXISTS
Чем заменить distinct в sql
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Универсальный метод один — использовать вместо DISTINCT GROUP BY.
На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
| От: | PPA | http://flylinkdc.blogspot.com/ |
| Дата: | 20.09.04 08:55 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Дубли убрать из набора данных без кей слова DISTINCT можно так:
1.
select a,b,c from t
group by a,b,c
2.
select a,b,c from t
union
select a,b,c from t where 1=2
3.
джойном(даже хитрым) имхо это сделать нельзя.
| От: | dvd00 |
| Дата: | 20.09.04 09:19 |
| Оценка: |
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, dvd00, Вы писали:
D>>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
S>Универсальный метод один — использовать вместо DISTINCT GROUP BY.
S>На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
S>Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
| От: | Softwarer | http://softwarer.ru |
| Дата: | 20.09.04 09:46 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
Оптимизация запроса — это вообще отдельная песня. Насколько я помню, кто-то здесь говорил, что в MS SQL distinct то ли заметно быстрее group by, то ли наоборот. В Oracle, например, они не то что одинаковы — физически одинаково выполняются.
Из общих соображений — надо все-таки посмотреть, из данных ли идет это дублирование, либо из плохо сконструированного запроса. Поскольку бывает, что в запросе оказывается что-нибудь типа select distinct master_id from details. На самом деле я не помню ни одного случая, когда мне приходилось в программе использовать distinct — каждый раз оказывалось, что вместо этого надо аккуратнее написать запрос.
| От: | Strong |
| Дата: | 21.09.04 13:18 |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Это можно сделать с помощью EXISTS.
Причем вариант 2 работает значительно быстрее, тк без Distinct нет необходимости в сортировке строк.
SQL Server 2014 Заменить Distinct? Деидентифицировать данные
Я собираюсь снова объяснить, что я пытаюсь сделать, в надежде, что вы можете помочь.
Таблица 1 содержит 4061 строку со столбцами, включающими [Имя], [Адрес1], [Адрес2], [Адрес3], [Город], [Штат], [Почтовый индекс], [Страна], [Телефон] и 20 других столбцов. Таблица 1 — это данные, которые необходимо деидентифицировать. Таблица 1 содержит 1534 отдельных строки [Имя] из 4061 строки.
Таблица 2 содержит автоматически сгенерированные данные, которые включают те же столбцы. Я хотел бы заменить вышеупомянутые столбцы в таблице 1 данными из таблицы 2. Я хочу выбрать разные на основе [Имя] из таблицы 1, а затем [Имя], [Адрес1], [Адрес2], [Адрес3], [ Город], [Штат], [Почтовый индекс], [Страна], [Телефон] с новым набором отдельных данных из таблицы 2.
Я не хочу просто обновлять каждую строку новым адресом, так как это нарушит согласованность данных. Заменив только отдельные, это позволит мне сохранить согласованность данных при изменении данных строки в таблице 1. Когда я закончу, я хотел бы иметь 1534 отдельных новых обезличенных [Имя] [Адрес1], [Адрес2], [Адрес3 ], [Город], [Штат], [Почтовый индекс], [Страна], [Телефон] в таблице 1 из таблицы 2.
2 ответа
Вот как я это сделал. Сначала я запустил оператор, чтобы выбрать отдельные, и вставил его в таблицу.
Затем я добавил столбец name2 в APMAST2 и использовал оператор для создания последовательного поля идентификатора в APMAST2.
Теперь у меня есть отдельная информация плюс пустое поле имени и поле последовательного идентификатора в APMAST2. Теперь я могу присоединиться к этой дате со своей таблицей fakenames, из которой я сгенерировал. ЗДЕСЬ, используя их массовый инструмент.
Используя оператор соединения, я объединил свои поддельные данные с APMAST2
Теперь у меня загружены поддельные данные, но я сохранил свое исходное поле Name, чтобы я мог перезагрузить эти данные в свою полную таблицу ARMAST, чтобы теперь я мог выполнить соединение между ARMAST2 и ARMAST.
Теперь в моей исходной таблице есть все фальшивые данные, но она сохраняет целостность, которую она имела, ну и большую часть, поэтому данные выглядят хорошо при составлении отчетов, но не идентифицируются. Теперь вы можете удалить APMAST2 или оставить его, если позже вам потребуется сопоставить его с другими данными. Я знаю, что это долго, и я уверен, что есть лучший способ сделать это, но я сделал это так, предложения приветствуются.
Чем заменить distinct в sql
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Универсальный метод один — использовать вместо DISTINCT GROUP BY.
На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
 | От: | PPA | http://flylinkdc.blogspot.com/ |
| Дата: | 20.09.04 08:55 | ||
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Не совсем очевидна твоя «проблема».
А какой смысл избавится от этого слова. ухо режет 
?
Дубли убрать из набора данных без кей слова DISTINCT можно так:
1.
select a,b,c from t
group by a,b,c
2.
select a,b,c from t
union
select a,b,c from t where 1=2
3.
джойном(даже хитрым) имхо это сделать нельзя.
 | От: | dvd00 |
| Дата: | 20.09.04 09:19 | |
| Оценка: |
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, dvd00, Вы писали:
D>>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
S>Универсальный метод один — использовать вместо DISTINCT GROUP BY.
S>На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
S>Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против 
Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
 | От: | Softwarer | http://softwarer.ru |
| Дата: | 20.09.04 09:46 | ||
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
Оптимизация запроса — это вообще отдельная песня. Насколько я помню, кто-то здесь говорил, что в MS SQL distinct то ли заметно быстрее group by, то ли наоборот. В Oracle, например, они не то что одинаковы — физически одинаково выполняются.
Из общих соображений — надо все-таки посмотреть, из данных ли идет это дублирование, либо из плохо сконструированного запроса. Поскольку бывает, что в запросе оказывается что-нибудь типа select distinct master_id from details. На самом деле я не помню ни одного случая, когда мне приходилось в программе использовать distinct — каждый раз оказывалось, что вместо этого надо аккуратнее написать запрос.
 | От: | Strong |
| Дата: | 21.09.04 13:18 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Это можно сделать с помощью EXISTS.
Причем вариант 2 работает значительно быстрее, тк без Distinct нет необходимости в сортировке строк.
Что быстрее, выберите DISTINCT или GROUP BY в MySQL?
если у меня есть таблица
и я хочу получить все уникальные значения profession поле, что было бы быстрее (или рекомендуется):
15 ответов
они по существу эквивалентны друг другу (на самом деле это как некоторые базы данных реализации DISTINCT под капотом).
когда в сомнении, тест!
если у вас есть индекс на profession эти два слова-синонимы.
GROUP BY на MySQL результаты разные. Вы даже можете сделать:
и получить ваши профессии отсортированы в DESC порядок.
DISTINCT создает временную таблицу и использует его для хранения дубликатов. GROUP BY делает то же самое, но сортирует различные результаты впоследствии.
все ответы выше верны, для случая DISTINCT на одном столбце vs GROUP BY на одном столбце. Каждый движок БД имеет свою собственную реализацию и оптимизацию, и если вы заботитесь о очень маленькой разнице (в большинстве случаев), то вам нужно протестировать против конкретного сервера и конкретной версии! Как реализации могут измениться.
но, если вы выбираете более одного столбца в запросе, то DISTINCT существенно отличается! Потому что в этом случае это будет сравнить все столбцы всех строк, а не только один столбец.
Так что если у вас есть что-то вроде:
Это распространенная ошибка думать, что ключевое слово DISTINCT различает строки по первому столбцу, который вы указали, но DISTINCT является общим ключевым словом таким образом.
таким образом, люди, Вы должны быть осторожны, чтобы не принимать ответы выше как правильные для всех случаев. Вы можете запутаться и получить неправильные результаты, в то время как все, что вы хотели, было оптимизация!
well distinct может быть медленнее, чем group by в некоторых случаях в postgres (не знаю о других dbs).
равна
похоже, что запросы не совсем одинаковы. По крайней мере для MySQL.
второй запрос дает дополнительно «использование filesort» в Extra.
(более функциональное Примечание)
есть случаи, когда вам нужно использовать GROUP BY, например, если вы хотите получить количество сотрудников на работодателя:
в таком случае DISTINCT u.employer работает неправильно. Возможно, есть способ, но я просто не знаю его. (Если кто-то знает, как сделать такой запрос с DISTINCT, пожалуйста, добавьте Примечание!)
Если вам не нужно выполнять какие-либо групповые функции (sum, average и т. д., Если вы хотите добавить числовые данные в таблицу), используйте SELECT DISTINCT. Я подозреваю, что это быстрее, но у меня нет ничего, чтобы показать это.
в любом случае, если вы беспокоитесь о скорости, создать индекс по столбцу.
после тяжелых испытаний мы пришли к выводу, что GROUP BY быстрее
выберите sql_no_cache opnamegroep_intern От telwerken Где opnemergroep IN (7,8,9,10,11,12,13) группа по opnamegroep_intern
635 totaal 0.0944 сек Weergave van records 0-29 (635 totaal, query duurde 0.0484 sec)
выберите sql_no_cache distinct (opnamegroep_intern) От telwerken Где opnemergroep IN (7,8,9,10,11,12,13)
635 totaal 0.2117 секунд ( почти 100% медленнее ) Weergave van records 0-29 (635 totaal, query duurde 0.3468 sec)
в моем проекте когда-то я использую group by и другие distinct
вот простой подход, который будет печатать 2 разных времени для каждого запроса.
Он просто отображает количество миллисекунд, необходимых для анализа, компиляции и выполнения каждого оператора, как показано ниже:
SELECT DISTINCT всегда будет одинаковым или быстрее, чем GROUP BY. В некоторых системах (например, Oracle) он может быть оптимизирован так же, как и для большинства запросов. На других (например, SQL Server) это может быть значительно быстрее.
Если проблема позволяет это, попробуйте с EXISTS, так как она оптимизирована для завершения, как только результат будет найден (и не буферизуйте какой-либо ответ), поэтому, если вы просто пытаетесь нормализовать данные для предложения WHERE, как это
более быстрый ответ был бы:
это не всегда возможно, но при наличии вы увидите более быстрый ответ.
COUNT DISTINCT и оконные функции
Мы без проблем можем посчитать общее количество ПК для каждого производителя, а также количество уникальных моделей данного производителя в таблице PC:
|
Если нам требуется получить детальную информацию о каждой модели, наряду с их общим количеством для каждого производителя, то можно использовать оконную функцию:
|
Теперь представим, что нам требуется дополнить эту информацию количеством уникальных моделей. Естественная попытка
Использование ключевого слова DISTINCT не допускается с предложением OVER.
Сообщение об ошибке ясно описывает проблему. Вопрос в том, как её обойти.
Использование подзапроса
|
Использование DENSE_RANK
Ключевое слово DISTINCTROW
Ключевое слово DISTINCTROW в SQL-выражениях используется в Access для ограничения возвращаемых записей. Оно не используется в SQL-языке других баз данных. В Access оно служит для предотвращения вывода дублирующихся записей. Это ключевое слово работает подобно предикату DISTINCT в других реализациях SQL, но действие DISTINCT внутри запроса распространяется только на поля. DISTINCTROW проверяет записи (даже если их полей нет в выражении SELECT).
Команда SELECT
SELECT — это первое слово запроса на выборку или на добавление. Команда SELECT используется для выбора поля (или полей), которое будет выводиться в результате.
После ключевого слова SELECT необходимо указать поля, которые нужно вывести. Если используется больше одного поля, то между полями нужно вставлять запятые:
Предикаты SELECT
В выражениях SELECT можно использовать несколько предикатов, приведенных ниже.
Эти предикаты служат для ограничения количества возвращаемых записей. В SQL-выражении их можно использовать с командой WHERE.
Предикат ALL назначен по умолчанию. Он выбирает все записи, которые в выражении SQL удовлетворяет условию WHERE. Указывать его необязательно, поскольку он назначен по умолчанию. Предикат DISTINCT необходимо включать, когда из запроса следует исключить одинаковые записи (рассматриваются только поля, включенные в запрос). Например, при создании запроса, выводящего идентификатор покупателя и день, в который он сделал заказ, нужно использовать следующее SELECT DISTINCT [CustomerlD], [OrderDate]
Если в таблицу Orders помещено два заказа одного покупателя за один день, то в результирующей таблице будет содержаться только одна запись. Предикат DISTINCT указывает Access, что, если отобранные поля содержат одинаковые значения, нужно выводить только одну запись. Даже если на самом деле в таблице Orders есть две различные записи, то отображена будет только одна из них. Предикат DISTINCT проверяет дублирование только для полей, указанных для просмотра.
Предикат DISTINCT предназначен для исключения записей, которые содержат повторяющиеся значения в отобранных полях. Для того чтобы запись была включена в результат выполнения запроса, значения в каждом поле, включенном в инструкцию SELECT, должны быть уникальными.
DISTINCTROW— это предикат, существующий только в Access. Он работает подобно предикату DISTINCT, но с одним большим отличием: DISTINCTROW проверят совпадение в таблице или таблицах всех полей, а не только выбранных. Предикат DISTINCTROW используется для исключения записей, повторяющихся полностью. Он влияет на результат только в том случае, если в запрос включены не все поля из анализируемых таблиц. Предикат DISTINCTROW игнорируется, если запрос содержит только одну таблицу.
Если, например, какому-либо покупателю в таблице Orders соответствуют две различные записи, то при использовании в предыдущем SQL-выражении distinctrow вместо DISTINCT будут выведены обе записи. Предикат DISTINCTROW проверяет совпадение всех полей в таблицах Customers и Orders. Если содержимое каких-либо полей различно (в данном случае — идентификатор заказа), то будут выведены обе записи.
Предикат ТОР, который также характерен только для Access, ограничивает число выводимых записей, удовлетворяющих условию WHERE. Предикат TOP предназначен для возврата определенного числа записей, находящихся в начале или в конце диапазона, описанного с помощью предложения ORDER BY. Например, ТОР 10 выводит только десять первых записей, удовлетворяющих условию WHERE.
Предикат ТОР имеет один необязательный параметр PERCENT (процент), который указывает не количество первых записей, а их процентное отношение к общему числу отобранных записей.