Время выполнения запроса

Модераторы: kdv, CyberMax

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Время выполнения запроса

Сообщение kdv » 18 фев 2009, 21:10

250 ms против 0.2 ms после добавления +0, последний, на котором я понял, что проблема какая-то системная - это 35x (3500%) - 7 ms против 0.2 ms после добавления +0.
я уже говорил, что для большинства приложений это не разница, особенно между 7 и 0.2 миллисекунд. На это вообще никто не смотрит.
Когда речь идет о разнице в миллисекунды нужно выбирать движок, а не крутить планы запросов туда-сюда.
Причем подобной непредсказуемости я раньше на firebird ни разу не встречал, а у меня на нем 2 проекта сделано. Возможно, что я просто грабли нужной стороной для наступания мог наконец повернуть, но может и поломал что.
это разница в плане. на разных объемах данных и разной статистике индексов. это - нормально.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 19 фев 2009, 17:16

kdv писал(а):
250 ms против 0.2 ms после добавления +0, последний, на котором я понял, что проблема какая-то системная - это 35x (3500%) - 7 ms против 0.2 ms после добавления +0.
я уже говорил, что для большинства приложений это не разница, особенно между 7 и 0.2 миллисекунд. На это вообще никто не смотрит.
Представьте себе сервер с нагрузкой в сотню запросов в секунду :)

Миллисекунды не важны, хотя нагрузка мала.
это разница в плане. на разных объемах данных и разной статистике индексов. это - нормально.
А можно ли статистику поломать и поправить неправильно? Как оценить, все ли с ней хорошо?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Время выполнения запроса

Сообщение kdv » 19 фев 2009, 18:23

Представьте себе сервер с нагрузкой в сотню запросов в секунду
я знал, что дойдет и до этого.
Представьте себе сервер ФБ с 300 одновременно что-то делающими пользователями, над базой размером 30 гигабайт.
Например. И это не сказать чтобы выдающийся случай.
Вы никак не можете разделить свои real-time требования к БД и функционирование обычной СУБД. Попробуйте mysql без транзакций и версионного движка. Он Вам даст нужную скорость. Или MS SQL в блокировочном (не версионном) режиме.
Для Вашей задачи чем тупее движок (storage) - тем лучше. Причем "тупее" в смысле Jet, dbf и так далее.
А можно ли статистику поломать и поправить неправильно? Как оценить, все ли с ней хорошо?
IBAnalyst, например. Но все же, см. предыдущий абзац.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 19 фев 2009, 19:03

kdv писал(а):
Представьте себе сервер с нагрузкой в сотню запросов в секунду
я знал, что дойдет и до этого.
Представьте себе сервер ФБ с 300 одновременно что-то делающими пользователями, над базой размером 30 гигабайт.
Например. И это не сказать чтобы выдающийся случай.
ну представил.

Скажем - службу 09. В час пик - пара клиентов в минуту на девочку - не сказки.

Итого: 300 * n (n - количество запросов на поиск, все же уложить поиск в 1 запрос сложно). Итого - 10 * n запросов в секунду. Тут напрягаться придется всяко не от 0.5 s - и 100 ms уже проблема. Но, конечно, 10ms еще можно простить ... но это, как Вы правильно заметили - не выдающийся случай.

Но тут все хорошо, потому что только чтение и система легко масштабируется.
Вы никак не можете разделить свои real-time требования к БД и функционирование обычной СУБД. Попробуйте mysql без транзакций и версионного движка. Он Вам даст нужную скорость. Или MS SQL в блокировочном (не версионном) режиме.
Для Вашей задачи чем тупее движок (storage) - тем лучше. Причем "тупее" в смысле Jet, dbf и так далее.
У простых движков полно своих ограничений. У MySQL - 1 индекс на поиск (может есть какие-то подвижки в этом, не знаю). jet - 1Г на файл БД + любит в непредсказуемые моменты сказать, что ему не хватает ресурсов на какой-то запрос, причем я не смог найти ответа на то, что ему не нравится. И туповат, а мне в отчетах нужны и сложные запросы.

Думал о тупом реалтайм движке с небольшой БД за сутки (поскольку реалтайм часть не нуждается в данных более чем за сутки) + немедленная репликация в БД продвинутого движка, но это сильно усложняет систему.

Поэтому пока что на всех реалтайм запросах тупо прибиваю план с помощью +0 и надеюсь на ФБ.
А можно ли статистику поломать и поправить неправильно? Как оценить, все ли с ней хорошо?
IBAnalyst, например. Но все же, см. предыдущий абзац.
В анализе он ничего интеерсного не говорит, а что смотреть на предмет "что тут не так" я не знаю

Tonal
Сообщения: 104
Зарегистрирован: 30 сен 2007, 13:42

Re: Время выполнения запроса

Сообщение Tonal » 20 фев 2009, 08:44

Может что-нибудь от Книжника подойдёт?

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Время выполнения запроса

Сообщение WildSery » 22 фев 2009, 16:24

pticelov писал(а):Скажем - службу 09. В час пик - пара клиентов в минуту на девочку - не сказки.
Итого: 300 * n (n - количество запросов на поиск, все же уложить поиск в 1 запрос сложно). Итого - 10 * n запросов в секунду. Тут напрягаться придется всяко не от 0.5 s - и 100 ms уже проблема. Но, конечно, 10ms еще можно простить ... но это, как Вы правильно заметили - не выдающийся случай.
Некорректное сравнение.
10*n запросов в секунду в одном коннекте, и 10*n запросов в 300 коннектов - две большие разницы.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 22 фев 2009, 17:30

WildSery писал(а):
pticelov писал(а):Скажем - службу 09. В час пик - пара клиентов в минуту на девочку - не сказки.
Итого: 300 * n (n - количество запросов на поиск, все же уложить поиск в 1 запрос сложно). Итого - 10 * n запросов в секунду. Тут напрягаться придется всяко не от 0.5 s - и 100 ms уже проблема. Но, конечно, 10ms еще можно простить ... но это, как Вы правильно заметили - не выдающийся случай.
Некорректное сравнение.
10*n запросов в секунду в одном коннекте, и 10*n запросов в 300 коннектов - две большие разницы.
Ну задержка у нас тут не с потолка берется - это же загрузка CPU + ожидание чтения в очереди к диску.

Загрузка CPU - все равно, в один коннект или в кучу, все равно суммируется. Что там с оптимизацией чтения - не знаю.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Время выполнения запроса

Сообщение WildSery » 23 фев 2009, 15:27

pticelov писал(а):Ну задержка у нас тут не с потолка берется - это же загрузка CPU + ожидание чтения в очереди к диску.
Загрузка CPU - все равно, в один коннект или в кучу, все равно суммируется. Что там с оптимизацией чтения - не знаю.
Т.е. у тебя всё в загрузку CPU и дисковой системы упёрлось?
Так что ты тогда на сервер БД жалуешься, если у тебя мощности железа не хватает?
Апгрейдь железо.
Либо попытайся перепланировать архитектуру так, чтобы не требовалось 10 запросов в секунду.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 26 фев 2009, 16:11

WildSery писал(а):
pticelov писал(а):Ну задержка у нас тут не с потолка берется - это же загрузка CPU + ожидание чтения в очереди к диску.
Загрузка CPU - все равно, в один коннект или в кучу, все равно суммируется. Что там с оптимизацией чтения - не знаю.
Т.е. у тебя всё в загрузку CPU и дисковой системы упёрлось?
Так что ты тогда на сервер БД жалуешься, если у тебя мощности железа не хватает?
Апгрейдь железо.
Либо попытайся перепланировать архитектуру так, чтобы не требовалось 10 запросов в секунду.
Да я это было боковое обсуждение ситуации работы под высокой нагрузкой с кучей пользователей (генерирующих те самые 10 запросов в секунду), как пример того, что плевать на неестественное лишнее время выполнения - глупо, иначе действительно придется апгрейдить железо там, где это не надо :)

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 26 фев 2009, 16:43

Лирика-лирикой, но попробуем вернуться к теме этого треда. У меня новый повод для ступора возник в отй же самой ситуации.

Итак - на некоторых часто выполняющихся запросах я благополучно добавил +0 и получил разумное время выполнения в доли миллисекунды там, где начали мы с 250 миллисекунд. И было у меня счастье, пока я в одном из отчетов не нашел вот такое (в общем, вариант того же запроса, что и раньше):

SELECT * FROM incalls where cid='тут подставляется номер телефона' order by id desc

запрос не prepard, поскольку выполняется 1 раз на отчет - выводит историю звонков, номер подставляется прямо в текст запроса. На первом fetch словил опять те же самые 250 ms, что были в начале треда (последующие выполнялись быстро). Поменял на +0, стало хорошо, но тут я задумался, что будет, если мы наткнемся на нехороший часто встречающийся номер (а такие есть). Естественно, оно будет тормозить, что и подтвердила практика - на запросе по номеру, встречающемуся 100000 раз (в базе из 1.5 миллиона записей) ФБ думал больше 500 мс при выполнении запроса. Эта задержка меня ничуть не удивила и обсуждать ее не интересно, но она заставила задуматься о том, что нужно какое-от другое решение, кроме +0.

И тут я решил посмотреть, как выполняются заросы без +0 при выборках номеров с разным количеством записей:
1. запрос с номером, встречающимся 1 раз в БД. первый fetch выполняется примерно 170 мс
2. запрос с номером, встречающимся 1156 раз в БД. первый fetch выполняется примерно 300 мс
3. Запрос с номером, встречающимся 105088 раз в БД, первый fetch выполняется 40 ms :)

Статистика по запросам, по порядку 1, 2, 3 по показания flamerobin:

Preparing query: SELECT * FROM incalls where cid='1234567' order by id desc

Prepare time: 00:00:00.
Field #01: INCALLS.ID Alias:ID Type:INTEGER
Field #02: INCALLS.CID Alias:CID Type:STRING(20)
Field #03: INCALLS.CALLTO Alias:CALLTO Type:STRING(20)
Field #04: INCALLS.STARTTIME Alias:STARTTIME Type:TIMESTAMP
Field #05: INCALLS.LENGTH Alias:LENGTH Type:INTEGER
Field #06: INCALLS.TOTALTALK Alias:TOTALTALK Type:INTEGER
Field #07: INCALLS.DISCREASON Alias:DISCREASON Type:SMALLINT
Field #08: INCALLS.CLIENT Alias:CLIENT Type:INTEGER
Field #09: INCALLS.WAITLENGTH Alias:WAITLENGTH Type:SMALLINT
Field #10: INCALLS.DIALLENGTH Alias:DIALLENGTH Type:SMALLINT
PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID))


Executing...
Done.
1492 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 13 index, 0 seq.
Delta memory: -18772 bytes.
Execute time: 00:00:00.
Script execution finished.


Preparing query: SELECT * FROM incalls where cid='2991112' order by id desc

Prepare time: 00:00:00.
Field #01: INCALLS.ID Alias:ID Type:INTEGER
Field #02: INCALLS.CID Alias:CID Type:STRING(20)
Field #03: INCALLS.CALLTO Alias:CALLTO Type:STRING(20)
Field #04: INCALLS.STARTTIME Alias:STARTTIME Type:TIMESTAMP
Field #05: INCALLS.LENGTH Alias:LENGTH Type:INTEGER
Field #06: INCALLS.TOTALTALK Alias:TOTALTALK Type:INTEGER
Field #07: INCALLS.DISCREASON Alias:DISCREASON Type:SMALLINT
Field #08: INCALLS.CLIENT Alias:CLIENT Type:INTEGER
Field #09: INCALLS.WAITLENGTH Alias:WAITLENGTH Type:SMALLINT
Field #10: INCALLS.DIALLENGTH Alias:DIALLENGTH Type:SMALLINT
PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID))


Executing...
Done.
4559 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 1036 index, 0 seq.
Delta memory: 18780 bytes.
Execute time: 00:00:01.
Script execution finished.

Preparing query: SELECT * FROM incalls where cid='#' order by id desc

Prepare time: 00:00:00.
Field #01: INCALLS.ID Alias:ID Type:INTEGER
Field #02: INCALLS.CID Alias:CID Type:STRING(20)
Field #03: INCALLS.CALLTO Alias:CALLTO Type:STRING(20)
Field #04: INCALLS.STARTTIME Alias:STARTTIME Type:TIMESTAMP
Field #05: INCALLS.LENGTH Alias:LENGTH Type:INTEGER
Field #06: INCALLS.TOTALTALK Alias:TOTALTALK Type:INTEGER
Field #07: INCALLS.DISCREASON Alias:DISCREASON Type:SMALLINT
Field #08: INCALLS.CLIENT Alias:CLIENT Type:INTEGER
Field #09: INCALLS.WAITLENGTH Alias:WAITLENGTH Type:SMALLINT
Field #10: INCALLS.DIALLENGTH Alias:DIALLENGTH Type:SMALLINT
PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID))


Executing...
Done.
3214 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 1036 index, 0 seq.
Delta memory: 515652 bytes.
Execute time: 00:00:00.
Script execution finished.


чего-то я ничего не понимаю, план - один и тот же, а время выполнения меняется столько специфически.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Время выполнения запроса

Сообщение kdv » 26 фев 2009, 17:48

чего-то я ничего не понимаю, план - один и тот же, а время выполнения меняется столько специфически.
можно вырезать информацию о столбцах, они тут ни при чем.
Не зря советовали прочитать www.ibase.ru/devinfo/dataaccesspaths.htm

план
PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID))
означает следующее -
берется индекс incid, и сервер по нему шурует в поиске ключей, попадающих под заданное условие.
Как находит - обращается к таблице, выводит запись, и едет дальше. Опять находит, и опять едет дальше.
потому и время для разных искомых значений - разное. Непонятно, почему это вызывает удивление.
Альтернатива - без индекса, sort всего набора, который попал в where. Время будет фиксированное, но возможно чуть дольше.
Для примера - два крайних случая, с сортировкой и без, по уникальным и неуникальным значениям:
http://forum.ibase.ru/phpBB3/viewtopic. ... 75&p=26455

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Время выполнения запроса

Сообщение WildSery » 26 фев 2009, 18:25

pticelov писал(а):И тут я решил посмотреть, как выполняются заросы без +0 при выборках номеров с разным количеством записей:
1. запрос с номером, встречающимся 1 раз в БД. первый fetch выполняется примерно 170 мс
2. запрос с номером, встречающимся 1156 раз в БД. первый fetch выполняется примерно 300 мс
3. Запрос с номером, встречающимся 105088 раз в БД, первый fetch выполняется 40 ms :)
Нет никакой зависимости от числа записей. Время первого фетча = сколько шуровать в порядке индекса до первой подходящей записи.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 26 фев 2009, 18:39

kdv писал(а):
план
PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID))
означает следующее -
берется индекс incid, и сервер по нему шурует в поиске ключей, попадающих под заданное условие.
Как находит - обращается к таблице, выводит запись, и едет дальше. Опять находит, и опять едет дальше.
потому и время для разных искомых значений - разное. Непонятно, почему это вызывает удивление.
Вообще-то тормоза связаны не с выборкой по INCID, а с сортировкой по id :)
Альтернатива - без индекса, sort всего набора, который попал в where. Время будет фиксированное, но возможно чуть дольше.
Неверно. При сортировке без индекса в самом худшем случае (это несколько значений CID, на которые приходятся порядка 10-100 тысяч записей) мы получаем чуть большее время, чем обычное значение для сортировки по индексу (в данном случае это около 200 мс в среднем), а на большинстве записей - вообще бесконечно малую величину.
Для примера - два крайних случая, с сортировкой и без, по уникальным и неуникальным значениям:
http://forum.ibase.ru/phpBB3/viewtopic. ... 75&p=26455
Цитирую:
"резюме для тех, кто не понял смысл:
...
3. выборка "в порядке индекса" моментально выдает первую порцию записей, но "тормозит" и создает высокий дисковый ввод-вывод по мере выборки остальных записей

4. для небольшого количества записей "стоимость" сортировки на диске или выборки в порядке индекса может быть одинаковой."

Я наблюдаю прямо противоположное:

1. при сортировке по индексу певый фетч тормозит нереально, дальше - работает быстро
2. для небольшого количества записей сортировка без индекса работает мгновенно, а с индексом - тормрза

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 26 фев 2009, 18:41

WildSery писал(а):
pticelov писал(а):И тут я решил посмотреть, как выполняются заросы без +0 при выборках номеров с разным количеством записей:
Нет никакой зависимости от числа записей. Время первого фетча = сколько шуровать в порядке индекса до первой подходящей записи.
Он "шурует" на большинстве записей по 200 мс. Нереально много. Памяти - вагон, количество кешируемых страниц в БД установлено по максимуму, вся БД целиком помещается в память сервера.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Время выполнения запроса

Сообщение kdv » 26 фев 2009, 19:25

Вообще-то тормоза связаны не с выборкой по INCID, а с сортировкой по id
иногда лучше читать, в смысле, посмотреть на план. и посмотреть, по каким столбцам построен индекс.
мне твои данные, индексы и столбцы пофиг, я тебе говорю что происходит в соответствии с планом.
Я наблюдаю прямо противоположное:
1. при сортировке по индексу певый фетч тормозит нереально, дальше - работает быстро
потому что первое искомое значение стоит "далеко" в индексе.
2. для небольшого количества записей сортировка без индекса работает мгновенно, а с индексом - тормрза
опять же, ты наверное невнимательно мою статью прочитал, или никак не можешь понять механизма выборки при PLAN ... ORDER INDEX.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 27 фев 2009, 00:18

kdv писал(а):я тебе говорю что происходит в соответствии с планом.
Ну а я комментирую, что ка краз на описываемой процедуре он и не тормозит, а тормозит на сортировке по ID.
Я наблюдаю прямо противоположное:
1. при сортировке по индексу певый фетч тормозит нереально, дальше - работает быстро
потому что первое искомое значение стоит "далеко" в индексе.
2. для небольшого количества записей сортировка без индекса работает мгновенно, а с индексом - тормрза
опять же, ты наверное невнимательно мою статью прочитал, или никак не можешь понять механизма выборки при PLAN ... ORDER INDEX.
Наверное :( Я вообще не понимаю, что может тормозить в сортировке по индексу одной записи, пр иглубине индекса 3 :( Это ж не 7 ms, это 170, и процессор далеко не 286.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: Время выполнения запроса

Сообщение hvlad » 27 фев 2009, 02:54

pticelov писал(а):Наверное :( Я вообще не понимаю, что может тормозить в сортировке по индексу одной записи, пр иглубине индекса 3 :( Это ж не 7 ms, это 170, и процессор далеко не 286.
Ибо совершенно не понимаешь, как работает PLAN ORDER.

PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID)) означает, что
а) сканируется индекс INCID в поисках ключей и строится битмап с номерами соотв. записей
б) сканируется индекс INCALLS_ID_D и каждый найденный в нём ключ проверяется на попадание в битмап.
Если попали - читаем запись из таблицы и выдаём её наружу.

В случае же с сортировкой шаг (б) отсутвует, но выполняется
в1) читаем все записи, чьи номера есть в битмапе
в2) сортируем полученный набор и выдаём его наружу

Почувствуй разницу

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 27 фев 2009, 03:19

hvlad писал(а):
pticelov писал(а):Наверное :( Я вообще не понимаю, что может тормозить в сортировке по индексу одной записи, пр иглубине индекса 3 :( Это ж не 7 ms, это 170, и процессор далеко не 286.
Ибо совершенно не понимаешь, как работает PLAN ORDER.

PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID)) означает, что
а) сканируется индекс INCID в поисках ключей и строится битмап с номерами соотв. записей
б) сканируется индекс INCALLS_ID_D и каждый найденный в нём ключ проверяется на попадание в битмап.
Если попали - читаем запись из таблицы и выдаём её наружу.

В случае же с сортировкой шаг (б) отсутвует, но выполняется
в1) читаем все записи, чьи номера есть в битмапе
в2) сортируем полученный набор и выдаём его наружу

Почувствуй разницу
Ну я всех деталей не знаю, но представлял именно так, правда не понимая, как оно устроено

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

Я почему-то предполагал второй вариант, но если там первый вариант - то это и впрямь жопа :(

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Время выполнения запроса

Сообщение kdv » 27 фев 2009, 10:54

а поиск - просмотр трех страниц (в соответствии с глубиной индекса)
мда, это уже начинает напоминать цирк. Глубина индекса определяет стоимость однократного поиска, т.е. выборки одного ключа, например в уникальном индексе. То есть, сколько страниц придется пройти от корневой до конечной, где находится ключ с указателем на номер записи.

Сканирование же индекса - это выборка ВСЕХ ключей, которые подходят под это условие. После выборки ключей над списком полученных номеров записей может быть выполнена сортировка. И т.д.
То есть при индексном поиске или выборке только одна операция может выполняться каждый раз за одно и то же время - это выборка ОДНОГО ключа в УНИКАЛЬНОМ индексе, или выборка группы ключей в неуникальном индексе где неуникальные значения РАВНОМЕРНО РАСПРЕДЕЛЕНЫ.
то это и впрямь жопа
это не жопа, это методы доступа к данным. В СУБД не бывает такого чтобы ЛЮБЫЕ операции независимо от данных выполнялись всегда за одно и то же время. Не нравится - придумай свою СУБД. Или используй ту, которая в требуемых тебе случаях будет давать одинаковое время на разных данных.

pticelov
Сообщения: 95
Зарегистрирован: 28 дек 2005, 22:52

Re: Время выполнения запроса

Сообщение pticelov » 27 фев 2009, 11:45

kdv писал(а):
а поиск - просмотр трех страниц (в соответствии с глубиной индекса)
мда, это уже начинает напоминать цирк. Глубина индекса определяет стоимость однократного поиска, т.е. выборки одного ключа, например в уникальном индексе. То есть, сколько страниц придется пройти от корневой до конечной, где находится ключ с указателем на номер записи.
Именно так. Так почему цирк?

Для выбора диапазона значений и нужен однократный поиск крайнего значений в диапазоне и дальше - выбор значений начиная от него и до второго края в сторону уменьшения или увеличения. По смыслу они должны находится в той же странице или рядом по дереву, если их много.
Сканирование же индекса - это выборка ВСЕХ ключей, которые подходят под это условие.
Это понятно. Вопрос-то был о том, сканируется ли весь индекс целиком или только его фрагмент.
то это и впрямь жопа
это не жопа, это методы доступа к данным. В СУБД не бывает такого чтобы ЛЮБЫЕ операции независимо от данных выполнялись всегда за одно и то же время. Не нравится - придумай свою СУБД. Или используй ту, которая в требуемых тебе случаях будет давать одинаковое время на разных данных.
Согласен, но мне почему-то казалось, что выбор оптимального метода доступа к данным - это работа СУБД. И сортировка набора из 10 записей должна вестись не так же, ка кнабора из 10 миллионов записей, и заботиться об этом должен движек СУБД. Может я и идеалист, но jet приучает к такой халяве, и я не думаю, что тут критично то, что это файлсерверный движек.

Ответить