... и так, чтобы полученный ряд хорошо ложился в статистики sqlserver.

Сломал голову. Решить не в состоянии, так как теорию вопроса уже забыл (да еще и не знал). Помогите!

Имеется некий набор значений, (n, m, k), который нужно отобразить на ряд целых чисел.
Набор значений k - может меняться, он монотонно растет (очень медленно)
Набор значений n, m - всегда неизменен.


Необходимо нарисовать некую функцию x=F(n, m, k), набор х значений которой удовлетворял бы следующим свойствам:
1. Каждому значению (n, m, k) должно соответствовать одно и только одно значение х, и каждому значению х должно соответствовать одно и только одно значение (n, m, k).
2. Набор значений х должен хорошо ложиться в правила формирования статистик mssqlserver, причем преимущественно адекватно должно оцениваться количество наборов с одинаковым k.
Т.е. наборы значений с одинаковым k должны ложиться примерно в один персентиль значений x, с т.з. формирования статистик mssqlserver.
3. Значения x, соответствующие одному k - должны быть интервальными, и не пересекающимися с другими значениями х наборов с другим k.
Т.е. всему множеству (n, m, 60) должен соответствовать некий интервал значений х, например 1...1000, причем никакому другому значению k тот же интервал соответствовать не должен. Т.е. ситуация, когда k = 60 соответствуют значения 1, 3, 5... а k=59 - 2, 4, 6 - недопустима.
4. Набор значений х должен быть максимально компактным. Вместе с тем условия непрерывности на ряд значений х - не накладывается. Т.е., совершенно необязательно, чтобы значения х шли без разрывов и max(x) - min(x) = 5124.
Требуется лишь чтобы по этому набору хорошо строилась статистика, см. п.2.
5. Предположим, у нас есть таблица n, m, k, x рассчитанная.
Значений:
0, 0, 60, х1 - 100
0, 1, 60, х2 - 1 млн.
1, 0, 60, х3 - 1
2, 0, 60, х4 - 10 тыс.
Оптимизатор, при запросе select * from tbl where x = x4 - должен или адекватно оценивать количество строк (10 тыс.), либо полагать их ~ 1 млн.

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

aleks222, Неа, не подходит.
Оно не дает int на выходе.
... а хотелось бы вообще smallint, но это мечты.
И гистограмма будет дырявая.

Фактически, переделы как раз и озвучены. Количество k может увеличиться на ~10 за несколько лет, количество значений n - на пару-тройку за несколько лет (но можно считать статическим).

Указанный алгоритм не подходит, интервалы получаются не-непрерывные по k, см. п.3.

К сожалению, студентом я был 30 лет назад :-(
В bit - хотелось бы, но, к сожалению 5 тыс. значений в трех измерениях в него не поместятся.

Размер имеет значение.

Подоплека задачи:

Имеется таблица, примерно на миллиард записей.
Каждую запись можно охарактеризовать группой из 3 признаков, в итоге - см. выше.
Хочется сопоставить этим признакам некое число, и использовать его:
1. Как ключ при разбиении на секции
2. Как хеширующий признак при выборках. Именно поэтому важна интервальность, прежде всего - по k, но желательно еще и по n

Сейчас ключ строится как: k*10000 + n * 1000 + m
Но у него совершенно жуткая статистика!
Размах значений в 60 тыс, причем значения разбросаны очень неравномерно.
В результате MSSQLSERVER строит совершенно жуткую гистограмму по этому полю.
Как результат оптимизатор периодически или ударяется в сканирование всего, или рисует нестед лупы, полагая, что для какого-то значения мало записей.
А количество записей с каждым признаком - действительно неравномерное. От 0 до 20-30 млн.
Собственно, поэтому и задача.

Плохая идея. k и n - могут измениться. При этом все признаки пересчитывать?
Т.е. последовательность целых чисел - неустойчиво к изменению количества признаков.

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

А непромокаемый порох давно изобретен.
В виде унитарного патрона :-)

felix_ff, да, но оно получается слишком грубым приближением.
Я не совсем правильно выразился.
Правильнее так:
Хочется, чтобы оптимизатор правильно оценивал статистику по (k, n, m).
Но уж если по какому то набору это не получается - пусть промахивается, и считает как по диапазону одного значения k, или его подмножеству.
Я понимаю, что 5000 значений в 200 интервалов не уместить, но хоть что-то в этом направлении сделать.

Кроме того ладно, пусть будет "как по k", только поле нужно всё равно кодирующее все 3 признака, и взаимооднозначно.

mayton, Ненене! Избыточно.
Возможные значения, собственно, перечислены в исходном запросе.
n - максимум 10, сейчас 5, и рост до 10 - в неопределенной перспективе, можно этим пренебречь.
k - 60, максимум - 100 значений.
m - в точности 12 (точнее, 11 и "прочее", так что 12).
Итого в ключе менее 10 тыс. вариантов.
И всё это нормально влазит в smallint. Проблема то как раз в том, чтобы сконструировать это значение таким образом, чтобы по нему нормально создавалась статистика.

felix_ff,
вам было предложено в виде "хеш-функции" взять бинарное представление, статистика по столбцу binary тоже строится нормально.

На маленьких примерах - всё замечательно работает.
Теперь представьте, что ключей ~ 5000, а количество входов по каждому ключу - от 1 (единицы) до 20 млн.
В среднем - порядка миллиона, но очень неровно.

В том то и дело что ничего.
Если ТС хочет добиться поведения при котором оптимизатор посмотрев объект статистики по любому ключу будет ему выдавать оценку как если бы бы этот самый ключ представлял RANGE_HIGH_KEY значение - то хер.

Лимит шагов в гистограмме 200. точное число строк выдается в виде EQ_ROWS если запрашивается ключ попадающий в RHK.
в случаях если в интервале лежат несколько ключей в расчет будет идти значение AVG_RANGE_ROWS, при этом если в интервале наблюдается сильная дисперсия значений то увы здесь ничего не поделаешь.
здесь только создавать фильтрованные статистики для большей детализации, но автоматом сиквел такую ситуацию не разрулит.
Ага, примерно этого и хочу, и понимаю, что это - невозможно.
Я понимаю, что 5000 уникальных ключей на 200 интервалов - не отобразишь.
И фильтрованная статистика - не годиться, т.к. она не бывает инкрементальной, а нужна именно инкрементальная.

Я хочу таким образом подобрать значения ключей, чтобы:
1) 1 ключу соответствовал один и только один набор этих трех параметров (n, m, k)
2) При построении статистики по записям с такими ключами статистика вела бы себя, в худшем случае, как построенная по полю k (60 уникальных входов, и в 200 шаговую диаграмму - замечательно укладывается целиком), но, возможно с несколько большей детализацией (т.к. значений k - 60, а шагов в гистограмме - в 3,5 раза больше).
3) При этом чтобы значение ключа было целым числом, а лучше smallint, ибо дорого.
И 4) Можно было достоверно сказать, что диапазон ключа between x1 and x2 - относится к одному и только одному значению k.

А именно так и сделано уже .
Просто ключ выбран, как мне видится - очень неудачно.
Сейчас он считается как: k*10000 + n * 1000 + m
И это приводит к тому, что набор значений ключа очень "полосатый". Разброс между минимальным значением и максимальным - 600 тыс., и значения ключа, которые соответствуют реальным координатам (n,m,k) - очень "островковые".
Это приводит к тому, что mssqlserver не может построить по нему адекватную гистограмму. Например, выпадают и неверно оцениваются промежутки, соответствующие некоторым k, и он начинает оценивать количество значений, как количество между неким k-3 и k+5 (например), что совсем не в ту степь, т.к., напоминаю, речь идет о миллионах записей.
Поэтому и хочется как то изменить алгоритм построения ключа, чтобы он стал статистически более равномерным, и гистограмма по нему выглядела, ну, как построенная по k в первом приближении. Или чуть более детально, чем по k (в k, напоминаю, 60 уникальных значений, и возможен рост до 100, но не более и не мгновенно, когда-нибудь, короче).

felix_ff статистика должна быть инкрементальной, т.к. таблица пополняется подменой секций. Если на таблице имеется не-инкрементальная статистика - выполнить switch partition не получится.

Я вот думаю, может ключ сделать char(4) и кодировать его значения в 16 или, скажем, 32-ричной системе?

Так он и участвует!
Это тот самый [key]. По нему секционирование и сделано.
И partition elimination тоже выполняется.
Проблема в том, что когда я указываю в запросе [key] = 6001012 (например), сервер оценивает количество записей не равному количеству в секции, а на основе статистике по этому полю, а она - дырявая, см. выше, и частенько полагает количество значений = 1,
Не смотря на то, что секция - полная, и в ней миллионы записей.

OPTIMIZE FOR - хорошая идея, попробую ее.

Кроме того, попробую посмотреть, как будет считаться статистика по такому ключу:
Cast(k as binary(1)) + Cast((n * 16) | Cast(m as binary(1)) as binary(1)) key_bin
Или
Cast(Cast(k as binary(1)) + Cast((n * 16) | Cast(m as binary(1)) as binary(1)) as smallint) key_int

Интересно, что получится.

Создал таблицу, на той же самой партишн схема, что и оригинальная таблица, но из 4х столбцов: кластерного индекса (ид строки + ключ партиционирования, старый), ключ small int, ключ binary(2).
Создал статистики по полям.
Удивительно, но получил разные характеристики статистики ключей в виде smallint и binary(2).
Причем существенно разные.
Не смотря на то, что это одни и те же данные в байтовом виде.
Почему так, интересно???
Причем, обратите внимание, в таблице 1437 уникальных значений ключа.
Почему для бинарного ключа другая плотность?
Я специально перепроверил - и там, и там значения, в смысле байтов - одинаковые.

Gerros, т.е. не только порезать данные на 5000 секций, но и на ~ 10 таблиц?
Теоретически - возможно, но боюсь оптимизатор с ума сойдет, строя планы по view из секционированных таблиц.
Фишка в том, что выборки считаются по всему набору данных, которые нужно пополнять большими кусками.

Три раза перепроверил - это одно и то же значение, если рассматривать бинарное представление. Т.е. я ничего не напутал. Одно и то же число в бинарном виде и в виде smallint в поле дает разную плотность и, гистограмму разную.
Причем, обратите внимание, в таблице 1437 уникальных значений ключа.
Плотность должна быть 1/1437 ~ 0.00006
Какого черта она для бинарного представления в два раза больше???

Ну, в моем варианте, скорее 60 таблиц, но не суть.
Это было опробовано.
Секционированное представление оказалось даже более "тормознутым", чем секционированная таблица.
Плюс ко всему, если запрос затрагивает несколько секций представления - сервер ошибается (в нашем случае) - еще фатальнее.
Хотя, в принципе, мы не исследовали вариант глубоко - может и прокатить.

Вьюха по таблицам сделает невозможным использование индекса.

Это почему это?
Нормальное секционированное представление. Констрейнт на ключ, по которому осуществляется секционирование, и создание выровненных индексов, по аналогии с секционированной таблицей - и всё нормально используется.
Разумеется ключ секционирования должен участвовать в запросе.
Второй вариант - таблица одна, но в ней 26 полей. Опять-таки гистограмма будет точная. При этом саму таблицу можно секционировать.
Нет это не тот случай.

Владислав Колосов, см. статистику по regstamp_bin

Владислав Колосов,
Это я нолик перекрутил, когда ответ печатал. :)
На картинке видно.

Для поля regstamp_int - плотность 1/1437, а для _bin - вдвое выше, не смотря на то, что это одно и то же число, в бинарном представлении.