SQL, Вспомогательная таблица чисел
https://stackoverflow.com/questions/10819
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Для определенных типов sql-запросов вспомогательная таблица чисел может быть очень полезна.Он может быть создан в виде таблицы с таким количеством строк, сколько вам нужно для конкретной задачи, или в виде определяемой пользователем функции, которая возвращает количество строк, требуемое в каждом запросе.
Каков оптимальный способ создания такой функции?
Решение
Хех...извините, что я так поздно ответил на старый пост.И, да, я должен был ответить, потому что самый популярный ответ (на тот момент, рекурсивный ответ CTE со ссылкой на 14 различных методов) в этой теме - это, ммм...производительность в лучшем случае под вопросом.
Во-первых, статья с 14 различными решениями хороша для того, чтобы увидеть различные методы создания таблицы чисел / подсчета "на лету", но, как указано в статье и в цитируемой теме, есть очень важная цитата...
"предложения относительно эффективности и производительности часто субъективны.Независимо от того, как используется запрос, физическая реализация определяет эффективность запроса.Поэтому, вместо того, чтобы полагаться на предвзятые рекомендации, крайне важно протестировать запрос и определить какой из них работает лучше ".
По иронии судьбы, сама статья содержит много субъективных утверждений и "предвзятых рекомендаций", таких как "рекурсивный CTE может генерировать список номеров довольно эффективно" и "Это эффективный метод об использовании цикла WHILE из публикации группы новостей Ицика Бен-Гена" (который, я уверен, он опубликовал только для сравнения).Давайте, ребята...Простое упоминание доброго имени Ицика может привести к тому, что какой-нибудь бедолага действительно воспользуется этим ужасным методом.Автор должен практиковать то, что он проповедует, и должен провести небольшое тестирование производительности, прежде чем делать такие смехотворно некорректные заявления, особенно перед лицом любой масштабируемости.
С мыслью о том, чтобы действительно провести некоторое тестирование, прежде чем делать какие-либо субъективные заявления о том, что делает тот или иной код или что кому-то "нравится", вот некоторый код, с помощью которого вы можете провести собственное тестирование.Настройте profiler для SPID, с которого вы запускаете тест, и проверьте это сами...просто выполните "Поиск по месту" числа 1000000 для вашего "любимого" номера и посмотрите...
--===== Test for 1000000 rows ==================================
GO
--===== Traditional RECURSIVE CTE method
WITH Tally (N) AS
(
SELECT 1 UNION ALL
SELECT 1 + N FROM Tally WHERE N < 1000000
)
SELECT N
INTO #Tally1
FROM Tally
OPTION (MAXRECURSION 0);
GO
--===== Traditional WHILE LOOP method
CREATE TABLE #Tally2 (N INT);
SET NOCOUNT ON;
DECLARE @Index INT;
SET @Index = 1;
WHILE @Index <= 1000000
BEGIN
INSERT #Tally2 (N)
VALUES (@Index);
SET @Index = @Index + 1;
END;
GO
--===== Traditional CROSS JOIN table method
SELECT TOP (1000000)
ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS N
INTO #Tally3
FROM Master.sys.All_Columns ac1
CROSS JOIN Master.sys.ALL_Columns ac2;
GO
--===== Itzik's CROSS JOINED CTE method
WITH E00(N) AS (SELECT 1 UNION ALL SELECT 1),
E02(N) AS (SELECT 1 FROM E00 a, E00 b),
E04(N) AS (SELECT 1 FROM E02 a, E02 b),
E08(N) AS (SELECT 1 FROM E04 a, E04 b),
E16(N) AS (SELECT 1 FROM E08 a, E08 b),
E32(N) AS (SELECT 1 FROM E16 a, E16 b),
cteTally(N) AS (SELECT ROW_NUMBER() OVER (ORDER BY N) FROM E32)
SELECT N
INTO #Tally4
FROM cteTally
WHERE N <= 1000000;
GO
--===== Housekeeping
DROP TABLE #Tally1, #Tally2, #Tally3, #Tally4;
GO
Пока мы этим занимаемся, вот цифры, которые я получаю из SQL Profiler для значений 100, 1000, 10000, 100000 и 1000000...
SPID TextData Dur(ms) CPU Reads Writes
---- ---------------------------------------- ------- ----- ------- ------
51 --===== Test for 100 rows ============== 8 0 0 0
51 --===== Traditional RECURSIVE CTE method 16 0 868 0
51 --===== Traditional WHILE LOOP method CR 73 16 175 2
51 --===== Traditional CROSS JOIN table met 11 0 80 0
51 --===== Itzik's CROSS JOINED CTE method 6 0 63 0
51 --===== Housekeeping DROP TABLE #Tally 35 31 401 0
51 --===== Test for 1000 rows ============= 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 47 47 8074 0
51 --===== Traditional WHILE LOOP method CR 80 78 1085 0
51 --===== Traditional CROSS JOIN table met 5 0 98 0
51 --===== Itzik's CROSS JOINED CTE method 2 0 83 0
51 --===== Housekeeping DROP TABLE #Tally 6 15 426 0
51 --===== Test for 10000 rows ============ 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 434 344 80230 10
51 --===== Traditional WHILE LOOP method CR 671 563 10240 9
51 --===== Traditional CROSS JOIN table met 25 31 302 15
51 --===== Itzik's CROSS JOINED CTE method 24 0 192 15
51 --===== Housekeeping DROP TABLE #Tally 7 15 531 0
51 --===== Test for 100000 rows =========== 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 4143 3813 800260 154
51 --===== Traditional WHILE LOOP method CR 5820 5547 101380 161
51 --===== Traditional CROSS JOIN table met 160 140 479 211
51 --===== Itzik's CROSS JOINED CTE method 153 141 276 204
51 --===== Housekeeping DROP TABLE #Tally 10 15 761 0
51 --===== Test for 1000000 rows ========== 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 41349 37437 8001048 1601
51 --===== Traditional WHILE LOOP method CR 59138 56141 1012785 1682
51 --===== Traditional CROSS JOIN table met 1224 1219 2429 2101
51 --===== Itzik's CROSS JOINED CTE method 1448 1328 1217 2095
51 --===== Housekeeping DROP TABLE #Tally 8 0 415 0
Как вы можете видеть, Рекурсивный метод CTE уступает только циклу While по длительности и процессору и имеет в 8 раз больший объем памяти в виде логических операций чтения, чем цикл While.Это RBAR на стероидах, и его следует избегать любой ценой при любых однострочных вычислениях точно так же, как следует избегать цикла While. Есть места, где рекурсия весьма ценна, но это НЕ одно из них.
В качестве дополнительного бара, мистерДенни абсолютно в точку попал...постоянные номера правильного размера или таблица подсчета - это правильный подход к большинству задач.Что означает правильный размер?Ну, большинство людей используют таблицу подсчета для генерации дат или для разделения в VARCHAR (8000).Если вы создадите таблицу подсчета 11 000 строк с правильным кластеризованным индексом на "N", у вас будет достаточно строк для создания дат на сумму более 30 лет (я много работаю с ипотеками, поэтому 30 лет для меня ключевое число) и, конечно же, достаточно для обработки разделения по переменной (8000).Почему "правильный размер" так важен?Если таблица подсчета используется часто, она легко помещается в кэш, что делает ее невероятно быстрой без особой нагрузки на память вообще.
И последнее, но не менее важное: каждый знает, что если вы создаете постоянную таблицу подсчета, не имеет большого значения, какой метод вы используете для ее построения, потому что 1) это будет сделано только один раз и 2) если это что-то вроде таблицы из 11 000 строк, все методы будут работать "достаточно хорошо". Так к чему все эти рассуждения с моей стороны о том, какой метод использовать???
Ответ заключается в том, что какой-нибудь бедный парень / девушка, который не знает ничего лучшего и которому просто нужно выполнить свою работу, может увидеть что-то вроде рекурсивного метода CTE и решить использовать его для чего-то гораздо большего и гораздо более часто используемого, чем создание постоянной таблицы подсчета, и я пытаюсь защитите этих людей, серверы, на которых работает их код, и компанию, которой принадлежат данные на этих серверах.Да...это настолько важно.Так должно быть и для всех остальных.Научите делать что-то правильно, а не "достаточно хорошо".Проведите некоторое тестирование, прежде чем публиковать или использовать что-либо из поста или книги...жизнь, которую вы спасаете, на самом деле может быть вашей собственной, особенно если вы считаете, что рекурсивный CTE - это способ добиться чего-то подобного.;-)
Спасибо, что выслушали...
Другие советы
Наиболее оптимальной функцией было бы использовать таблицу вместо функции.Использование функции приводит к дополнительной загрузке процессора для создания значений для возвращаемых данных, особенно если возвращаемые значения охватывают очень большой диапазон.
Эта статья дает 14 различных возможных решений с обсуждением каждого из них.Важным моментом является то, что:
предложения относительно эффективности и результативности часто субъективны.Независимо от того, как используется запрос, физическая реализация определяет эффективность запроса.Поэтому, вместо того, чтобы полагаться на предвзятые рекомендации, крайне важно протестировать запрос и определить какой из них работает лучше.
Лично мне понравилось:
WITH Nbrs ( n ) AS (
SELECT 1 UNION ALL
SELECT 1 + n FROM Nbrs WHERE n < 500 )
SELECT n FROM Nbrs
OPTION ( MAXRECURSION 500 )
Этот просмотр выполняется очень быстро и содержит все положительные моменты int ценности.
CREATE VIEW dbo.Numbers
WITH SCHEMABINDING
AS
WITH Int1(z) AS (SELECT 0 UNION ALL SELECT 0)
, Int2(z) AS (SELECT 0 FROM Int1 a CROSS JOIN Int1 b)
, Int4(z) AS (SELECT 0 FROM Int2 a CROSS JOIN Int2 b)
, Int8(z) AS (SELECT 0 FROM Int4 a CROSS JOIN Int4 b)
, Int16(z) AS (SELECT 0 FROM Int8 a CROSS JOIN Int8 b)
, Int32(z) AS (SELECT TOP 2147483647 0 FROM Int16 a CROSS JOIN Int16 b)
SELECT ROW_NUMBER() OVER (ORDER BY z) AS n
FROM Int32
GO
Используя SQL Server 2016+ для создания таблицы чисел вы могли бы использовать OPENJSON :
-- range from 0 to @max - 1
DECLARE @max INT = 40000;
SELECT rn = CAST([key] AS INT)
FROM OPENJSON(CONCAT('[1', REPLICATE(CAST(',1' AS VARCHAR(MAX)),@max-1),']'));
Идея взята из Как мы можем использовать OPENJSON для генерации рядов чисел?
Редактировать:смотрите комментарий Конрада ниже.
Ответ Джеффа Модена великолепен...но я нахожу в Postgres, что метод Itzik завершается с ошибкой, если вы не удалите строку E32.
Немного быстрее на postgres (40 мс против 100 мс) - это еще один метод, который я нашел на здесь адаптировано для postgres:
WITH
E00 (N) AS (
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 ),
E01 (N) AS (SELECT a.N FROM E00 a CROSS JOIN E00 b),
E02 (N) AS (SELECT a.N FROM E01 a CROSS JOIN E01 b ),
E03 (N) AS (SELECT a.N FROM E02 a CROSS JOIN E02 b
LIMIT 11000 -- end record 11,000 good for 30 yrs dates
), -- max is 100,000,000, starts slowing e.g. 1 million 1.5 secs, 2 mil 2.5 secs, 3 mill 4 secs
Tally (N) as (SELECT row_number() OVER (ORDER BY a.N) FROM E03 a)
SELECT N
FROM Tally
Поскольку я перехожу с SQL Server на Postgres world, возможно, я пропустил лучший способ создания таблиц подсчета на этой платформе ...ЦЕЛОЕ число()?ПОСЛЕДОВАТЕЛЬНОСТЬ()?
Еще намного позже я хотел бы внести немного другой "традиционный" CTE (не затрагивает базовые таблицы для получения объема строк):
--===== Hans CROSS JOINED CTE method
WITH Numbers_CTE (Digit)
AS
(SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9)
SELECT HundredThousand.Digit * 100000 + TenThousand.Digit * 10000 + Thousand.Digit * 1000 + Hundred.Digit * 100 + Ten.Digit * 10 + One.Digit AS Number
INTO #Tally5
FROM Numbers_CTE AS One CROSS JOIN Numbers_CTE AS Ten CROSS JOIN Numbers_CTE AS Hundred CROSS JOIN Numbers_CTE AS Thousand CROSS JOIN Numbers_CTE AS TenThousand CROSS JOIN Numbers_CTE AS HundredThousand
Этот CTE выполняет больше операций чтения, чем CTE Ицика, но меньше, чем традиционный CTE.Однако он последовательно выполняет меньше операций записи, чем другие запросы. Как вы знаете, запись неизменно обходится намного дороже, чем Чтение.
Продолжительность сильно зависит от количества ядер (MAXDOP), но на моем 8core выполняется стабильно быстрее (меньшая продолжительность в мс), чем другие запросы.
Я использую:
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
на Windows Server 2012 R2, 32 ГБ, Xeon X3450 с частотой 2,67 ГГц, 4 ядра с поддержкой HT.
