| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Скорость выборки
Piter © (2004-12-18 18:50:00)Есть такое выражение:
'SELECT Count(n) From MyTable Where n=0'
Выборка длится около 4 секунд :(
Всего записей в базе 4700.
Почему так медленно? Правда, стоит заметить, что это только первый раз так долго. Потом такие выражения выполняются не более 100 мс, но все равно - загрузка программы происходит очень долго из-за этого.
Такое ощущение, что это как бы инициализация работы с таблицей. То есть, при первой выборке из этой таблице что-то там делается долго, после чего последующие выборки из этой таблицы отрабатывают оперативно. Ну это мне так кажется.
Можно как-нибудь ускорить процесс? А то 4 секунды - это перебор все таки, имхо, на Athlon 1800. Не понимаю, как тогда работают базы с миллионами записей...
Использую базу Firebird Embedded
Nikolay M. (2004-12-19 15:44:00) [81]
> PLAN(TREE INDEX(TREE_ID))
Какие поля входят в этот индекс? И как называется индекс по полю n? Не знаю точно, как это будет у ИБ, но, имхо, индекс по n тут не используется. ы?
Кстати, могу еще предположить, что у ИБ count() работает как-то хитро, попробуй удалить индекс на n и повторить эксперимент?
Piter (2004-12-19 15:34:00) [82]Итак, опыты провожу в IBConsole (ну нету у меня IBExpert и трафика нет, чтобы скачать):
1)SELECT count(n) FROM Tree WHERE n=3
Execution Time: 3:0297
Prepare Time: 0
Starting Memory: 9141244
Current Memory: 9180156
Delta Memory: 38912
Number of buffers: 2048
Reads: 752
Writes: 5
Plan: PLAN(TREE INDEX(TREE_ID))
Запрос вернул Count=2206
При повторном запуске числа практически теже, только:
Execution Time: 0:0016
2)select first(1) from Tree Where n=3
Token unknown - line 1, char 17
from
3)select * from Tree Where n=3
Execution Time: 0:0094
Prepare Time: 0:0031
Starting Memory: 9151480
Current Memory: 9195512
Delta Memory: 44032
Number of buffers: 2048
Reads: 74
Writes: 9
Plan: PLAN(TREE INDEX(TREE_ID))
Повторный запрос выполняется вообще за время ноль :)
Если после
select * from Tree Where n=3
выполнить
SELECT count(n) FROM Tree WHERE n=3
- то последний все равно выполняется больше 3-х секунд.
Sergey_Masloff (2004-12-19 15:12:00) [83]Nikolay M. © (19.12.04 15:06) [27]
>А где написано про современный компьютер?
Я имею в виду начиная с DX4-100 c 32Mb RAM.
У меня есть система работающая уже скоро 8 лет, из них 6 я к ней не прикасался. Сервер IBM PC/2 DX2-66 16 Mb RAM (вернее на моей памяти доставляли до 32 Mb) 6 пользователей в одноранговой сети. Таблица из 4000 записей - это семечки даже для такой "системы".
Nikolay M. (2004-12-19 15:06:00) [84]
> Sergey_Masloff (19.12.04 15:01) [25]
А где написано про современный компьютер? Атлон 1800? Дык может у автора памяти 64 и винт на 2?
Тут еще встречал советы по поводу расширения у файла БД - какие-то расширения винда считает своими (слышал звон...). Точнее не скажу, т.к. с ИБ не работаю.
Anatoly Podgoretsky (2004-12-19 15:05:00) [85]Памяти добавь, винчестера побыстрее.
Если хватает, то учти следующее, что в первый раз данные берутся из диска в кэш, п последующии операции уже из кэша.
Это при условии, что все остальное ты сделал правильно и все нам рассказал, в чем сомневаюсь, поскольку за тобой замечена выдача не полной информации по проблеме.
Sergey_Masloff (2004-12-19 15:01:00) [86]Nikolay M. © (19.12.04 14:02) [22]
В таблице 4000 записей. Есть индекс, нет индекса, используется он или нет - на современном компьютере и интербейзе он все равно 4 секунды не будет выполняться.
DrPass (2004-12-19 14:59:00) [87]
> Возможно, просто файл БД хочет дефрагментации
>
> а почему повторно запрос отрабатывает очень быстро, да и
> впоследствии все работает хорошо?
Потому что кешируется операционкой. Подозреваю, что файл не слишком большой. Кроме того, 4700 записей - это ничтожный размер даже для тупого перебора без индексов, 4 сек. тут многовато
Piter (2004-12-19 14:56:00) [88]Nikolay M. © (19.12.04 14:02) [22]
Тогда похоже на то
что тогда похоже на то? :)
Я просто спросил - почему. Реально значения не только 0-1
А как ты представляешь себе грамотную индексацию поля, в котором есть, скажем, только значения 0/1?
а я вообще себе индексацию не представляю :(
или до него еще есть какие-либо запросы?
есть, но из других таблиц
Nikolay M. (2004-12-19 14:02:00) [89]
> Piter © (19.12.04 00:48) [17]
> А какие еще есть значения, кроме 0?
>
> 0-15 где-то...
>
> Если только 0/1, то, конечно, индекс при выборке не будет
> использоваться
>
> а почему?
Тогда похоже на то. Посмотри план своего запроса, подозреваю, что индекс в нем не используется.
А как ты представляешь себе грамотную индексацию поля, в котором есть, скажем, только значения 0/1?
AlterEgo of WondeRu (2004-12-19 13:13:00) [90]Piter © (18.12.04 20:38) [7]
Хм, инциализацию данной таблицы проводить на другой таблице? Как ты себе это представляешь...
у тебя данный запрос первый идет? или до него еще есть какие-либо запросы? как быстро они выполняются?
поробуй выполнить свой запрос в IBExpert'e
Sergey_Masloff (2004-12-19 09:11:00) [91]Piter © (19.12.04 00:48) [17]
>НУ хорошо, хорошо. А как ты объяснишь:
>Piter © (18.12.04 22:47) [12]
>Если закрыть программу, а потом опять открыть
см. [14] 3 абзац. Если сделано то опиши результаты. Если нет то не вижу базы для дальнейших теоретических рассуждений. Причин может быть миллион и если просто в уме их перебирать - не хватит жизни. Знаешь же метод двоичного спуска? Так чтобы отсекать половинки нужны эксперименты, без этого никак.
Piter (2004-12-19 03:20:00) [92]SergP © (19.12.04 1:50) [18]
Первый запрос после подключения к базе всегда долго отрабатывается
ну не 4 секунды же...
SergP (2004-12-19 01:50:00) [93]Хм... У меня с access'ом аналогичная ситуация...
Да и ранее наблюдал такое и с MySQL и с Oracle.
Первый запрос после подключения к базе всегда долго отрабатывается...
А что касается акцесса, то первый запуск проги долго отрабатывается (там призапуске идет подключение к базе и несколько запросов), при следующих запусках все сравнительно быстро. Но если почистить память, то следующий запуск снова долго происходит.
ИМХО то что в твоем случае - вполне нормально.
Piter (2004-12-19 00:48:00) [94]Sergey_Masloff (18.12.04 23:30) [14]
Никакого противоречия. До закрытия программы у тебя висит заинтересованная транзакция и мусора нет. В момент закрытия происходит автокоммит и все ненужное становится мусором
НУ хорошо, хорошо. А как ты объяснишь:
Piter © (18.12.04 22:47) [12]
Если закрыть программу, а потом опять открыть - то все будет быстро отрабатывать. Если перезагрузиться, то опять в первый раз будут тормоза.
Nikolay M. © (18.12.04 23:31) [15]
А какие еще есть значения, кроме 0?
0-15 где-то...
Если только 0/1, то, конечно, индекс при выборке не будет использоваться
а почему?
Piter (2004-12-19 00:36:00) [95]DrPass © (18.12.04 22:58) [13]
Win9x?
win2000
Возможно, просто файл БД хочет дефрагментации
а почему повторно запрос отрабатывает очень быстро, да и впоследствии все работает хорошо?
Nikolay M. (2004-12-18 23:31:00) [96]А какие еще есть значения, кроме 0? Если только 0/1, то, конечно, индекс при выборке не будет использоваться, будет тупой scan table.
Sergey_Masloff (2004-12-18 23:30:00) [97]Piter © (18.12.04 22:47) [12]
>То есть, данная выборка делается в начале работы программы. И >делается она очень долго почему-то.
Никакого противоречия. До закрытия программы у тебя висит заинтересованная транзакция и мусора нет. В момент закрытия происходит автокоммит и все ненужное становится мусором.
>А так как firebird embedded, то наверное никакого там мусора не >остается.
А что ембеддед запрещает параллельные транзакции одного приложения? И они механизм версионности переписали специально для emb? Сомневаюсь (уверен что это не так).
Вобщем, экспериментируй. Уверен что это именно выборка тормозит? Если сделаешь select first(1) from MyTable Where n=0 тормозит также? A select * from MyTable Where ID = 0? Если да то это не сборщик мусора а иначе проверяй дальше. Отключи допустим сборку мусора. Или перед запуском программы сделай базе бэкап-рестор. При этом гарантировано в базе мусора нет - те же тормоза?
DrPass (2004-12-18 22:58:00) [98]Подозреваю, что проблема в таком случае кроется не в СУБД, а в операционке. Win9x?
Возможно, просто файл БД хочет дефрагментации. Попробуй сначала backup-restore, потом дефрагментацию
Piter (2004-12-18 22:47:00) [99]Piter © (18.12.04 18:50)
Правда, стоит заметить, что это только первый раз так долго. Потом такие выражения выполняются не более 100 мс, но все равно - загрузка программы происходит очень долго из-за этого
То есть, данная выборка делается в начале работы программы. И делается она очень долго почему-то.
А так как firebird embedded, то наверное никакого там мусора не остается.
Если закрыть программу, а потом опять открыть - то все будет быстро отрабатывать. Если перезагрузиться, то опять в первый раз будут тормоза.
P.S. Page Size = 4096, если это важно...
Sergey_Masloff (2004-12-18 20:49:00) [100]Ну в смысле 100000 тебя притормозит значительно дольше чем на 4 секунды, возможно успеешь кофе сходить попить ;-) А твои 5000 если из них апдейтилось процентов 30 пару-тройку секунд могут дать.
| |
Страницы: 