Есть ли предел для n. записей при обработке запроса SQL?

Question

Скажем, у меня есть две таблицы:

таблица A с 6000 записями (т. Е. T ( A ) = 6000)

таблица B с 400 000 записями (т. Е. T ( B ) = 400000)

по какой-то причине я решил, что для моегоПоследний запрос Мне нужно было бы дважды соединить А с В, но я решил сделать это (предположительно) очень неэффективно через декартово произведение.Поэтому я бы сделал A * B * B , т. Е. T ( A ) * T ( B )* T ( B ) = что является внезапно квадриллионом записей, которые обрабатываются внутренне (например, для чередования с десятками с помощью выбора и проекции).

Хотя может быть неэффективным, справится ли это со средним сервером?Если так, есть ли предел, даже теоретически.Что делать, если таблицы были на величины больше?

Answer 1

Вы путаете модель обработки logic с тем, что фактически происходит внутри базы данных.

Проекция и выбор, и декартовы произведения - понятия из реляционной алгебры. Это объясняет , что делает SQL. не объясняется, как базы данных делают это.

В частности, базы данных имеют множество алгоритмов, которые поддерживают объединение и агрегирование таблиц. Базы данных также имеют вспомогательные структуры данных, в частности, индексы и разделы, которые позволяют проводить дальнейшую оптимизацию.

Если у вас нет условий join, фильтрации или агрегации, то базе данных не нужно генерировать декартово произведение - и это может быть довольно дорого.

В целом, однако, базы данных не генерируют декартово произведение. Если бы они это сделали, базы данных были бы не очень полезны.

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

Answer 2

Ваш вопрос является гипотетическим и может привести к ответам, основанным на мнении, но я дам ему шанс.

Вы говорите, что из своего декартового произведения вы намереваетесь вернуть только дюжину или около того записей. Если эти записи можно найти по индексам, «средний» сервер должен быть абсолютно нормальным - не имеет значения, сколько записей в телефонной книге, если вы выполняете поиск по фамилии, ваш поиск будет быстрым. Если вы ищете 2 телефонные книги для 2 фамилий, все еще хорошо.

Если нужно найти 12 строк, которые нужно найти для простого сравнения неиндексированных полей, то это , вероятно, нормально - самая большая таблица - только 400К строк, и это должно быть довольно быстро. Если вы ищете название улицы в телефонной книге, размер телефонной книги имеет значение, но современное оборудование должно быть в порядке. Хотя лучше поставить индекс по столбцу.

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