MS Access перестает работать, когда я открываю запрос, имеющий 20 миллионов записей с одним видом

Question

MS Access перестает работать, когда я открываю запрос, имеющий 20 миллионов записей с одним видом

0

У меня есть запрос, который объединяет разные таблицы без какой-либо ссылки, поэтому он создает комбинацию. Число записей достигло 20 миллионов, я отсортировал эти записи по одному полю. MS Access зависает и перестает работать. Пожалуйста, любой, кто может помочь в ускорении запроса или заставить его работать. Спасибо

Hamza Rehman Saleemi 13 авг. 2018, в 14:31

Источник

4

С этими цифрами вам нужно перейти на взрослую РСУБД.
P.Salmon 13 авг. 2018, в 12:13
0

Можете ли вы поделиться более подробной информацией об исходных данных? Доступ имеет ограничение по размеру. Вы пробовали добавлять по одному и смотреть, как увеличивается размер БД? Они в разных БД или в одной?
Nathan_Sav 13 авг. 2018, в 12:14
0

Для обработки такого большого JOIN вам понадобится довольно много свободного места. Если возможно, попробуйте уточнить свой запрос, чтобы отбросить как можно больше ненужных комбинаций. Кроме того, есть ли у исходных таблиц подходящие индексы?
FDavidov 13 авг. 2018, в 12:36
0

Ограничение размера доступа еще не достигнуто. В настоящее время он составляет 500 МБ, так что это не тот случай, я думаю. Проблема возникает, когда я добавляю критерии сортировки в одно поле
Hamza Rehman Saleemi 13 авг. 2018, в 12:49
0

@FDavidov На самом деле их было более 500 миллионов. Я отфильтровал их до 20 миллионов. Таблицы также нормализованы. Запрос работает нормально, если я не добавляю никаких критериев (он просто показывает 20 миллионов) Но если я добавлю сортировку, чтобы увидеть верхнюю часть одного поля, доступ не поддерживает
Hamza Rehman Saleemi 13 авг. 2018, в 12:51
0

Похоже, вы используете нож для масла, когда вам нужен нож для стейка. Вы должны обратить внимание на обновление базы данных базы данных до чего-то более разумного. Доступ действительно не предназначен для обработки такого количества данных.
user2366842 13 авг. 2018, в 13:17
0

@HamzaRehmanSaleemi, я полностью согласен с user2388842. Насколько я помню (вы можете захотеть Google по этому вопросу), доступ имеет ограничение на размер ответа на запрос.
FDavidov 14 авг. 2018, в 13:14

Показать ещё 5 комментариев

Теги:

mysql

database

vba

sql

ms-access

2 ответа

Ещё вопросы

С этими цифрами вам нужно перейти на взрослую РСУБД.
Можете ли вы поделиться более подробной информацией об исходных данных? Доступ имеет ограничение по размеру. Вы пробовали добавлять по одному и смотреть, как увеличивается размер БД? Они в разных БД или в одной?
Для обработки такого большого JOIN вам понадобится довольно много свободного места. Если возможно, попробуйте уточнить свой запрос, чтобы отбросить как можно больше ненужных комбинаций. Кроме того, есть ли у исходных таблиц подходящие индексы?
Ограничение размера доступа еще не достигнуто. В настоящее время он составляет 500 МБ, так что это не тот случай, я думаю. Проблема возникает, когда я добавляю критерии сортировки в одно поле
@FDavidov На самом деле их было более 500 миллионов. Я отфильтровал их до 20 миллионов. Таблицы также нормализованы. Запрос работает нормально, если я не добавляю никаких критериев (он просто показывает 20 миллионов) Но если я добавлю сортировку, чтобы увидеть верхнюю часть одного поля, доступ не поддерживает
Похоже, вы используете нож для масла, когда вам нужен нож для стейка. Вы должны обратить внимание на обновление базы данных базы данных до чего-то более разумного. Доступ действительно не предназначен для обработки такого количества данных.
@HamzaRehmanSaleemi, я полностью согласен с user2388842. Насколько я помню (вы можете захотеть Google по этому вопросу), доступ имеет ограничение на размер ответа на запрос.

Stephen Turner · Answer 1 · 2018-08-13T10-14-00.000Z

Объединение таблиц, не сообщая о том, как связать одну таблицу с другой, называется "кросс-объединением", как вы говорите, оно создает комбинацию записей.

Легко получить очень большие результаты с использованием кросс-соединения, всего 5000 строк в каждой из двух таблиц в перекрестном соединении будут генерировать 25 миллионов записей, всего 300 записей в каждой из трех таблиц дадут 27 миллионов. При наличии всего 5000 или 300 записей в таблице MSAccess будет летать, но попросить его запустить запрос для создания записей ~ 20M потребуется время, именно так оно и есть.

Я предлагаю вам рассказать нам, что вы пытаетесь сделать, я ожидаю, что между таблицами должна быть связь или, по крайней мере, что-то в запросе, чтобы сообщить MSAccess, какой из записей 20M вы хотите видеть. Я ожидаю, что вы не захотите прокручивать через 500 000 страниц данных, чтобы найти то, что вы ищете.

У меня есть игроки за разными столами, и я делаю комбинацию команд (я уже пробовал разные методы, запрос составляется быстрее всего). Я создал комбинацию команд, которые изначально составляют 600 миллионов, но по различным критериям я отфильтровал их до 20 миллионов , Теперь я хочу видеть лучшие команды по количеству набранных очков, поэтому, когда я применяю сортировку к полю очков (по убыванию), он перестает работать.
Подумайте о том, что вы на самом деле говорите. Вы говорите, чтобы посмотреть на (предположительно рассчитанный) счет. Он должен рассчитать количество баллов для каждой из 20 миллионов записей и поместить те, которые набрали наивысшие баллы, в верхнюю часть и упорядочить остальные из них таким же образом. Это большая работа, особенно для инструмента, который не особенно хорошо разработан для обработки больших наборов данных. То, что вы МОЖЕТЕ попытаться сделать, - это внести top 50 (или 20 ... или 100) в свои записи, чтобы вы не возвращали ВСЕ данные, а только те, которые вас интересуют ... это все еще может быть медленным, хотя.

Gustav · Answer 2 · 2018-08-13T12-18-00.000Z

Один из методов заключается в изменении запроса на запрос create-table без использования фильтров.

Затем создайте индексы в новой таблице в полях, которые вы хотите фильтровать.

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