Очень долго выполняется запрос

Запрос выполняется минут десять. Разве так должно быть?

Обрисовываю ситуацию. Берутся две главные таблицы и одна связующая со связями многие ко многим. Главные таблицы состоят из двух колонок. Одна - ключ, а вторая - текст. Первая таблица 2000 строк. Вторая - 10000 строк. Связующая таблица состоит из ключей первой и второй. Но она гигантская по размерам - 500'000 строк. Сама задача проста. Связать первую и вторую таблицы если из первой таблицы запросу соответствуют 1000 строк, а из второй 5000 строк.

Последовательность примерно такая. Сначала запрос к каждой строке первой таблицы. Это 2000 операций. Из них останутся 1000 строк. Затем самое страшное. 1000 строк полученных сравниваются с 500'000 строк связующей таблицы. Это значит 1000 х 500'000 = 500'000'000 операций. В итоге останется 5000 строк в промежуточной таблице. Дальше попроще, выбираем из второй таблицы по полученному ключу. Это еще 5000 х 10'000 = 50'000'000 операций. В итоге сумма канечно устрашающая 550'002'000. Это только операции сравнения. Операций считывания посчитать проще. Разом все 2000 строк из первой, разом все 500'000 строк из связующей и разом все 10'000 строк из второй. Причем разом они должны намного быстрее делаться, чем по отдельности.

Вопрос знатокам, а сколько у вас ориентировочно будет выполняться такой запрос? И еще какие есть способы ускорить процесс не изменяя базы данных?

0

непрочной вам стенки в таком случае...

0

Сообщение от WirusaNet Мне сначала нужно понять, почему БД выполняет не оптимальный алгоритм?

Может это тебе только кажется?

Сообщение от WirusaNet Может ли она вообще выполнить более оптимальный алгоритм? И что нужно сделать для того?

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

Сообщение от WirusaNet Может быть окажется, что БД может выполнять и мой алгоритм.

Для этого производители СУБД должны предоставлять определенный API, а они, как уже было сказано, его не предоставляют.

0

Большая база уже удалена. Есть тока уменьшенная. Пример проблемного запроса.

Главная таблица 2679 записей. Связующая 24074 записи. На выполнение данного запроса уходит 20 секунд. Это очень долго для элементарного запроса.

При запросе плана выполнения запроса выдает:

	0	Trace	0	0	0		00
	1	Null	0	1	0		00
	2	Goto	0	19	0		00
	3	OpenRead	0	22439	0	1	00
	4	OpenRead	1	22449	0	3	00
	5	Rewind	0	13	0		00
	6	Rewind	1	12	0		00
	7	Column	0	0	2		00
	8	Column	1	2	3		00
	9	Ne	3	11	2	collseq(BINARY)	6b
	10	AggStep	0	0	1	count(0)	00
	11	Next	1	7	0		01
	12	Next	0	6	0		01
	13	Close	0	0	0		00
	14	Close	1	0	0		00
	15	AggFinal	1	0	0	count(0)	00
	16	SCopy	1	4	0		00
	17	ResultRow	4	1	0		00
	18	Halt	0	0	0		00
	19	Transaction	0	0	0		00
	20	VerifyCookie	0	462	0		00
	21	TableLock	0	22439	0	tt3	00
	22	TableLock	0	22449	0	to123	00
	23	Goto	0	3	0		00

Для большой базы думаю план должен быть такой же. И даже на урезаной базе производительность очень низкая.

0

Простите, не узнаю вас в гриме... (с)
Версию SQL озвучьте?

В плане не отражено использование индексов для поиска данных, поэтому, вероятнее всего, ускорить запрос поможет индекс:Кроме того, насколько я понял из плана, в tt3 22439 строк, а в to123 - 22449 строк, что отличается от заявленных вами. Возможно, требуется обновить статистику на сервере.

0

Версия SQLite. Индексов нет, это точно. А вот в таблице tt3 именно 2679 записей. Самому интересно как так. Могу тока предположить что когда то максимальное число записей в этой таблице было именно 22439. Но они уже удалены.

Если отойти от индексов. Разве без них должен именно так медленно выполнятся данный запрос.

0

Сообщение от WirusaNet Версия SQLite. Индексов нет, это точно. А вот в таблице tt3 именно 2679 записей. Самому интересно как так. Могу тока предположить что когда то максимальное число записей в этой таблице было именно 22439. Но они уже удалены. Если отойти от индексов. Разве без них должен именно так медленно выполнятся данный запрос.

Да, так и должно быть.

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

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

Ваша задача - предоставить оптимизатору возможность построить действительно быстрый план обработки.

Добавлено через 2 минуты
сделайте индекс и потом снова покажите план выполнения запроса?

0

Сообщение от WirusaNet Если отойти от индексов. Разве без них должен именно так медленно выполнятся данный запрос.

Если нет индексов, то выполняется FULL SCAN каждой таблицы, входящей в выборку. В этом случае действительно (во всяком случае в Oracle) читаются все блоки, которые были заполнены, даже если в них уже не осталось ни одной строки (если таблица после удаления не подвергалась сжатию).

0