Виснет SQL

← →
Silenser (2002-12-04 07:40) [0]

подскажите у меня запрос там три файла dbf один из них 17 мегов
при активизации запроса он виснет наглухо, если беру базу с меньшим объемом то нормально.... И КАК РАБОТАТЬ СО ЗДОРОВЫМИ БАЗАМИ

← →
Alex45 (2002-12-04 09:25) [1]

Всё зависит от запроса. Попробуй его оптимизировать. 17Мб - это прилично, но вовсе не много. А лучше пользуйся как минимум Интербэйсом.

← →
passm (2002-12-04 10:30) [2]

Silenser © (04.12.02 07:40)> КАК РАБОТАТЬ СО ЗДОРОВЫМИ БАЗАМИ Индексировать...

← →
sniknik (2002-12-04 11:10) [3]

17Мб даже очень мало. работаю с файлами ~ от 0 до 25мг (в среднем одна посылка 28-30мг. в 11 файлах) и они даже и неиндексированы (не нужно при передаче), потом все это уходит в MSSQL и там маштабы немного :-) другие.

а вот в программе которая мне эти данные передает есть таблици (в разных местах разные) до 120мг (и еще растут). и ничего индексы только время от времени летят (но не изза программы чаще чтото случается, свет выключат упсов нет или как одна тетка заявила "он так противно запищал я его выключила" а программу предварительно недоперла :-)).

p.s. все дело в твоем запросе. может ему действительно индекс нужен или места не хватает обьеденение сделать или .и.тд. исходных данных маловато.

← →
Anatoly Podgoretsky (2002-12-04 12:28) [4]

А может ты просто недождался окончания запроса.
17 мб для dbf это не много, много там начинается после 100 мб или 100 000 записей

← →
silenser (2002-12-05 12:31) [5]

Окончания я ждал очень долго, подвисла дельфя конкретно
вот сам запрос
select * from newpodr a, shtat b, dolg c
where b.ceh=a.n1 and
b.otdel=a.n2 and
b.buro=a.n3 and
b.gruppa=a.n4 and
c.kod_dolg=b.kod_dolg and
c.kod_d2=b.kod_d2
order by b.Kod_kor,b.ceh,b.otdel,b.buro,b.gruppa,b.kod_dolg,b.kod_d2

← →
Fiend (2002-12-05 14:27) [6]

думаю шо Анатолий прав на сто процентов. ты просто не дождался окончания выполнения запроса.
да и индексов надо подбросить по любому.
сам посмотри сколько условий+три таблицы+17Мб
Учти шо всё это драйвер раскладывает в так называемое декартово произведение этих трёх таблиц, так шо в итоге обрабатывает не 17 а поболе мегабайт. Если добавишь индексов дело пойдёт намного быстрее. Хотя драйвер может не усечь какие именно использовать если их будет несколько. Тада надо явно указать

← →
sniknik (2002-12-05 14:49) [7]

Декартово произведение это матрица всех возможных комбинаций.
Количество строк в декартовом произведении равно числу строк первой таблици умноженному на число строк второй таблици.
(простое обьеденение по одному полю 2-х таблиц, больше еще множ)

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

← →
atmamont (2002-12-05 19:24) [8]

короче отсюда вывод - надо читать книжки по SQL и писать запросы не "абы работало", а думать как оно будет отрабатываться на сервере. Как минимум вместо произведения использовать JOIN

← →
Anatoly Podgoretsky (2002-12-05 19:46) [9]

Короче тебе надо подождать несколько суток, прежде чем говорить, что зависло. Объем перератываемых данных у тебя явно будет выражать многими гигабайтами, хорошо еще если твои таблицы смогут разместиься в памяти. Кроме самой выборки по условию, ты еще и выводишь все поля, плюс конечная сортировка.
Смотри что у тебя получается для одной записи из А
сначала проверяются все записи в Б по цеху, затем по отделу и так далее.
Как минимум у тебя произведение A*B*C

Виснет SQL Найти похожие ветки