Таблица типа

create table TAB (
x smallint not null,
y smallint not null,
id_ver smallint not null,
size int not null,
......,
constraint PK_TAB primary key (x, y, id_ver)
)

Оба x и y принимают любые значения от 0 до 4095 каждое (4096*4096 = 16 777 216). Большие значения исключены на 100%.
id_ver думаю в реальности будет никак не более 10 штук, в среднем наверное 2.
Сабжевые значения числа записей реально достижимы.
Больше никаких альтернативных индексов нет.

Предполагаются запросы вида:
1. select ... where x=20 and y=44.
2. select ... where x=20 and y=44 and id_ver=2.
3. select ... where x=20 and y=44 and id_ver<=8.
4. select ... where (x between 20 and 30) and (y between 44 and 48).

В select этих запросов - только x, y, id_ver (то есть тут попадание в ПК).
Однако в любом из этих запросов может быть условие на size=0 или size<>0, что конечно изгадит всю "красоту" и полезет в таблицу.

Модификацию данных не рассматриваем (только insert и select, ну ещё будет delete).

А теперь идея. При сохранении в БД сдвигать X на 1 разряд и прибавлять 1 если size=0.
Соответственно запросы выше видоизменяются на:
1. select ... where (x between 40 and 41) and y=44.
4. select ... where (x between 40 and 61) and (y between 44 and 48).
причём условие на size=0 или size<>0 даже опускаем (хотя по идее и его можно добавить).

Теперь по результатам select-а не вылезая из полей ПК сразу видим на клиенте size=0 или size<>0.
При полном сохранении возможности работы по диапазонам.

Предполагается что двух записей с x=40 и x=41 при равных остальных полях y и id_ver залетать не будет.

Вопросы:
1. Кто-нибудь юзал такие "феньки" при условии, что реально используемая "мощность" ПК на пару порядков меньше его ширины (здесь достаточно было бы 2 полуторабайтных целых поля, в сумме лишний байт получается)?
2. Есть ли основания предполагать, что из-за замены x=20 на (x between 40 and 41) и (x between 20 and 30) на (x between 40 and 61) хоть сколько-нибудь что-нибудь "просядет"?

ChAвыигрыш в целом неочевиден
Ну выигрыш именно чтобы только по данным ПК поиметь знание принака size=0.
Большего не требуется. Но это - важно.

ChAесли такой ключ сделать кластерным
Разумеется.

ChAсразу получаешь данные из поля size
Не понял. Если к запросам добавить and size=0 - почему ничего не изменится в смысле IO?

Злой Бобрпри таком объеме данных проще сделать выборку по ПК и потом уже из нее условие по size
Имеешь в виду select x,y,id_ver,size from tab where <тут нет условия для size>?

Злой БобрКто-то слегка промахнулся при создании базы
Базы ещё нет. Это некая таблица, одна из десятков тыщ других похожих. Где-то больше записей, где-то меньше, но в некоторых оно точно будет достижимо под завязку. Слить в одну нельзя по причине слишком уж сурового общего количества записей (рабочий максимум порядка 300 млрд., в реальности наверное 1 млрд.) и непрогнозируемого их распределения.

Злой Бобрнеуказана БД
БД - любая из "взрослых" РСУБД (скажем, из "большой пятёрки"), причём предполагается что уровень знаний в администрировании этой СУБД у пользователя не обязательно выше среднего (максимум - выделил память и место, привязал кэш и настроил рост девайсов). На особенности раскидывания по кэшам и всяким партициям закладываться нельзя.

Уверен. Ибо данные уже и так есть. По шкафам на винтах. Надо запихнуть их в БД.

Dimitry Sibiryakovесли даже не пытался?
Я как бы сильно не первый день замужем. И знаю характерные отличия устриц от г-на в контексте общения с теми, кто их ел либо не ел.
Основное написано выше:
БД - любая из "взрослых" РСУБД (скажем, из "большой пятёрки"), причём предполагается что уровень знаний в администрировании этой СУБД у пользователя не обязательно выше среднего (максимум - выделил память и место, привязал кэш и настроил рост девайсов). На особенности раскидывания по кэшам и всяким партициям закладываться нельзя.

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

Вариант всё слить в одну таблу при наличии пряморукого DBA безусловно будет, но поскольку он совершенно тривиальный с точки зрения DML - рассматривать его на форуме глупо.

Кроме того, здесь приведена не вся информация о таблице и не все возможные запросы. Будет например select * по диапазону xy и order by id_ver desc. Полей ещё на 20 байт + image (в терминах MSSQL).

Дружище, она зависит даже от того, влезет ли индекс в кэш (здесь=оперативку), и если влезет - то сколько.

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

Dimitry SibiryakovНет разницы между чтением десяти страниц индекса из двадцати или десяти из тысячи. Это те же десять чтений.
Это в идеальном мире. В реальном мире будут важны не 10 абстрактных чтений индекса, а скажем так, мат.ожидание IO (а ещё точнее - общего времени ответа на запросы, но тут всё будет упираться в IO). Несмотря на то что xy определены для SELECT как диапазон - "окно" это может располагаться во всём множестве определения xy совершенно произвольно. Понятно что вследствие ограниченности памяти возможно придётся решать, что пришпилить в кэш (скажем так, часто используемое), а что пусть подтягивается и сливается на общих основаниях. Кроме того я указал, что тащиться будет не только ПК, но и хвост (иногда с image, иногда - без), так что с точки зрения попадания всех запрошенных данных в кэш в памяти всё несколько более напряжно, чем хотелось бы.

softwarer(с константами)
Я пока что предполагаю использовать для XY константы, а не параметры, диапазон окна будет порядка 10-20.

softwarer(x, y, id_ver, size)
Идея с покрывающим индексом понятна. Тем более что внезапно(!) обнаружилась ещё одна вещь, признак которой хотелось бы более или менее халявно подтягивать в запросе, и которая семантически неплохо "ложится" в size (в минус).
То есть сама задача именно к этому и подталкивает )))