Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Оптимизация запроса [D6, MySQL]

Страницы: 1 2 3 >
Andrey © (2004-05-31 10:13:00)
Проблема в следующем: при попытке выполнить запрос к таблице, состоящей из 6,000,000 записей, комп выполняет его где-то секунд 30. Открытие той же таблицы через TTable (с установленным индексом) происходит почти сразу (через пару секунд). Отсюда и вопрос, что делать? (без запроса не обойтись)

Izyum (2004-06-01 10:36:00) [1]
так если все живет через БДЕ, если мне память не врет, Query сначала стягивает все НД на локальный комп, а потом их обрабатывает, а Table действительно фетчит их при необходимости... Отсюда и мнимое преимущество TTable...

Vlad (2004-05-31 17:58:00) [2]

> Курдль © (31.05.04 17:52) [56]

Речь о результирующем наборе данных, там же не 6 млн записей, а к примеру 100-200, это должно быстро срабатывать даже при полном фетче.

Курдль (2004-05-31 17:52:00) [3]
А о чем тогда сыр-бор? 30 секунд для MySQL и указанного в [4] запроса с выборкой 6 000 000 записей - это невероятно быстро!

Vlad (2004-05-31 17:49:00) [4]

> Курдль © (31.05.04 17:47) [54]

Так и есть, все настройки в BDE алиасе, в т.ч. и курсор (клиентский/серверный), а так же количество записей в одном пакете (ROWSETSIZE)

Курдль (2004-05-31 17:47:00) [5]

> Открытие той же таблицы через TTable (с установленным индексом)
> происходит почти сразу (через пару секунд).

А Вы уверены, что TTable фетчит все записи? Мне сдается, что она показывает малую часть НД и подгружает по мере скроллинга.

Anatoly Podgoretsky (2004-05-31 16:54:00) [6]
Странно, выходит что сначала выбрали базу, а потом стали разбираться подходит она или нет. Обычно делают наоборот.

Andrey (2004-05-31 16:10:00) [7]

> Чтож, поздравляю :-)
> Если верить твоим словам, вывод можно сделать только один
> - в MySQL либо нет оптимизатора запроса либо он просто корявый.

У меня вывод более радикальный: херня это полная. Как говорится, бесплатный сыр только в мышеловке.

Но я все равно не понял, почему не выполняется такой простой запрос. Хотя, фиг с ним.

Vlad (2004-05-31 16:02:00) [8]

> Andrey (31.05.04 15:58) [50]

> В MS SQL работает. Можешь поздравить :)

Чтож, поздравляю :-)
Если верить твоим словам, вывод можно сделать только один - в MySQL либо нет оптимизатора запроса либо он просто корявый.

Andrey (2004-05-31 15:58:00) [9]

> Без необходимых индексов и там работать не будет.

В MS SQL работает. Можешь поздравить :)

> Вот так прям взяли и исчезли ? :-)

Да, причем три раза подряд. С базой работаю только я, права у меня только на чтение, т.е. я сам стереть никак не могу. Мистика, блин :)

Vlad (2004-05-31 14:17:00) [10]

> Andrey (31.05.04 14:15) [48]

> В общем, принято радикальное решение снести к черту MySQL
> и использовать MS SQL

Без необходимых индексов и там работать не будет.

> Терпение кончилось, когда из таблицы contract исчезли 75%
> записей.

Вот так прям взяли и исчезли ? :-)

Andrey (2004-05-31 14:15:00) [11]
В общем, принято радикальное решение снести к черту MySQL и использовать MS SQL. Терпение кончилось, когда из таблицы contract исчезли 75% записей.

Andrey (2004-05-31 11:57:00) [12]
Напишу минут через 30. Сейчас убегаю на обед :)

sniknik (2004-05-31 11:55:00) [13]
> причем вешается Windows. Можно как-нибудь эту проблему обойти?
конечно! переходи на линух, будет вешатся он.

индексы то добавил? и освети текушее положение дел, если ты думаеш что мы в курсе то глубоко ошибаешся. особенно интересно что скрывается за глубокомыссленным "Не пашет".

Andrey (2004-05-31 11:45:00) [14]
Ладно, идем другим путем. Делаю через Table, добавил lookup-поля из client и contract. В Filter написал ctp_auto= or ...

Далее, во время выполнения, добавляется еще одно ограничение (не по ctp_auto, а по другому полю). Причем строчка длинная (OR повторяется примерно 500 раз), и опять зависает, причем вешается Windows. Можно как-нибудь эту проблему обойти?

Andrey (2004-05-31 11:38:00) [15]
Блин, похоже, совсем беда.

Удалил данные (заново импортировал за неделю). Теперь в contract примерно 10000 записей, в client - около 4000. Не пашет. Не может же такого быть! Запрос ведь примитивный совсем.

sniknik (2004-05-31 11:35:00) [16]
еше попробуй делять явное присоеденение (INNER JOIN)
и индексы обязательно сделай.

Vlad (2004-05-31 11:35:00) [17]

> Andrey (31.05.04 11:32) [40]
> Да я попробовал - один <censored> не пашет.

Значит однозначно дело в индексах.
То есть у тебя не хватает индекса(ов) по каким-то полям используемым в where

Vlad (2004-05-31 11:33:00) [18]

> sniknik © (31.05.04 11:31) [39]

На небольших объемах (100-200 тыс) это не заметно, зато начинает здорово сказываться при объеме свыше 1 млн.
Тоже самое относится и к between - также серьезно затормаживает выборку, причем никакие индексы не спасают

Andrey (2004-05-31 11:32:00) [19]
Да я попробовал - один хер не пашет.

Может, MySQL плохо делает декартово произведение или вообще тупит при работе с большими таблицами?

sniknik (2004-05-31 11:31:00) [20]
может оптимизатор с OR не справляется? на access/MSSQL такого не замечал.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »