значительно быстрее запрашивать разные таблицы, чем с предложением where

Question

представьте, что у нас есть эта таблица:

create table Foo(
id int,
name varchar,
k int --can be 1 or 2 or 3
)

или мы можем иметь 3 таблицы для каждого значения k

create Fook1(
id int,
name varchar
)
...
create table Fook2
...
createa table Fook3

это будет значительно быстрее:

select * from Foo where k = 3

чем занимались:

select * from Fook3

Answer 1

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

Тем не менее, вы можете получить преимущества от обоих: разбиение таблицы .

Answer 2

-Не делай-то-

Ой, подождите, это не полезно, это просто так:)

Разделение данных таким способом МОЖЕТ привести к повышению производительности.Но они также приводят к другим затратам:
- Запросы, которые должны охватывать все три таблицы, становятся более сложными
- Ваша схема становится более загроможденной
- Легче делать ошибки
- Трудно обеспечить ссылочную целостность
- Вам может понадобиться включить представление для объединения трех таблиц

Скорее всего, вам гораздо лучше с индексом, в котором есть k.И в зависимости от того, как вы запрашиваете данные, k может быть первым полем в этом индексе.Когда вы указываете k = ?, ему просто нужно выполнить очень быструю проверку индекса, а затем вы смотрите только на соответствующую часть таблицы.И, если индекс равен clustered, данные даже физически хранятся в таком порядке.

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

Answer 3

Это может зависеть от БД, поэтому нужен реальный пример. Например, в Oracle вы можете использовать разбиение, которое делает именно то, что вы здесь говорите за кулисами, или создать материализованное представление с объединением, а затем иметь возможность сделать и то, и другое. Обычно я бы сказал, что вы должны создать правильную реализацию, а затем настроить; ранняя оптимизация - корень всех зол, особенно с БД. Я думаю, что вполне вероятно, что ваше узкое место не будет там, где вы ожидаете.