Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.06.27;
Скачать: CL | DM;

Вниз

Оптимизация запроса   Найти похожие ветки 

 
Andrey   (2004-05-31 11:32) [40]

Да я попробовал - один хер не пашет.

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


 
Vlad ©   (2004-05-31 11:33) [41]


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

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


 
sniknik ©   (2004-05-31 11:35) [42]

еше попробуй делять явное присоеденение (INNER JOIN)
и индексы обязательно сделай.


 
Vlad ©   (2004-05-31 11:35) [43]


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

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


 
Andrey   (2004-05-31 11:38) [44]

Блин, похоже, совсем беда.

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


 
Andrey   (2004-05-31 11:45) [45]

Ладно, идем другим путем. Делаю через Table, добавил lookup-поля из client и contract. В Filter написал ctp_auto= or ...

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


 
sniknik ©   (2004-05-31 11:55) [46]

> причем вешается Windows. Можно как-нибудь эту проблему обойти?
конечно! переходи на линух, будет вешатся он.

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


 
Andrey   (2004-05-31 11:57) [47]

Напишу минут через 30. Сейчас убегаю на обед :)


 
Andrey   (2004-05-31 14:15) [48]

В общем, принято радикальное решение снести к черту MySQL и использовать MS SQL. Терпение кончилось, когда из таблицы contract исчезли 75% записей.


 
Vlad ©   (2004-05-31 14:17) [49]


> Andrey   (31.05.04 14:15) [48]


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

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


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

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


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


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


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


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


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


 
Vlad ©   (2004-05-31 16:02) [51]


> Andrey   (31.05.04 15:58) [50]


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

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


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


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


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

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


 
Anatoly Podgoretsky ©   (2004-05-31 16:54) [53]

Странно, выходит что сначала выбрали базу, а потом стали разбираться подходит она или нет. Обычно делают наоборот.


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


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

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


 
Vlad ©   (2004-05-31 17:49) [55]


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

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


 
Курдль ©   (2004-05-31 17:52) [56]

А о чем тогда сыр-бор? 30 секунд для MySQL и указанного в [4] запроса с выборкой 6 000 000 записей - это невероятно быстро!


 
Vlad ©   (2004-05-31 17:58) [57]


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

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


 
Izyum ©   (2004-06-01 10:36) [58]

так если все живет через БДЕ, если мне память не врет, Query сначала стягивает все НД на локальный комп, а потом их обрабатывает, а Table действительно фетчит их при необходимости... Отсюда и мнимое преимущество TTable...



Страницы: 1 2 вся ветка

Текущий архив: 2004.06.27;
Скачать: CL | DM;

Наверх




Память: 0.58 MB
Время: 0.048 c
3-1086239467
Inkotex
2004-06-03 09:11
2004.06.27
IBDataBase


3-1085941851
Viktor
2004-05-30 22:30
2004.06.27
Перекодировка таблиц


6-1083687195
Popov Denis
2004-05-04 20:13
2004.06.27
Как "поймать" широковещательный udp пакет?


14-1086759922
Andrey007
2004-06-09 09:45
2004.06.27
Плавающее Access Violation


3-1086261004
Serg
2004-06-03 15:10
2004.06.27
Управление нижним скроллером в DBGrid