Здравствуйте.
Подскажите пожалуйста.
Есть табличка БД mvke(не буферизованная). Делаю 100000 отдельных select-ов из неё по первичному ключу и засекаю время выполнения.
Рассмотрел два случая:
1) если табличка mvke пустая то 100000 отдельных select-ов выполняются 21, 258 секунд
2) если в табличка mvke заполнена 1.5 милионов строк время выполения 21, 747 секунд.

Т.е время выполнения при пустой табличке и заполненной 1.5 миллионами строк почти не отличается( примерно 21 секунда) если делаем селект по первичному ключу.


Меня интерисует что будет с временем выполнения данной программки
если в табличке mvke будет несколько сотен миллиардов строк. Время выполнения тоже будет примерно 21 секунда? И есть ли какая-то формула по-которой можно вычислить время запроса в зависимости от числа записей в табличке БД(считывание происходит по первичному ключу)?

Мнэээ. очень странный эксперимент. Таблица-то не буферизованная, ага... в сапе. А вот на уровне СУБД все равно есть кэширование. Так что, начиная с определенного момента, запрос просто читает данные из буфера СУБД, тем более что читаете-то вы все время одну и ту же строку. Ну и как мне кажется, наиболее инетерсным с точки зрения производительности должен быть случай, когда искомой записи в субд просто нет.

А если в цикле do 100000 times ...endo читать всегда разные строчки и этих строчек не будет в табличке mvke никогда..то насколько быстрее будет выполняться такая программка при пустой табличке mvke и при заполненной несколькими миллионами строк?

Чтение из заполненной таблицы будет происходить в общем случае медленнее. Но на чтение оказывает влияние большое количество разных факторов: наличие данных в кэше, загрузка сети, читаются ли данные по 1 записи или пачками, наличие и качество статистики, как данные разложены физически. Если СУБД оракл, то для примерной оценки используют cost из плана запроса в st05
В деталях данную тему можно разъяснить для себя прочитав вот эту книгу

С точки зрения производительности поиск по ключу примерно то же самое что поиск в отсортированном массиве. Соответственно время работы = O( ln(N) ), где O - линейная функция, N - число элементов (строк). Или то же самое можно записать по другому: K*ln(N), где K - константа. Предполагается что прочие факторы (загрузка сети и т.д.) не зависят от N и включены в константу K

ваш эксперимент просто показал, что 1 строка все равно буферизуется
попробуйте добавить bypassing buffer

да, да эксперимент провалился:D
Причем bypassing buffer тоже погоды не сделал.

Как в случае пустой таблицы mvke, так и в случае заполненной время осталось тем же, примерно 21 секунда. Похоже буферизация на уровне СУБД и при bypassing buffer осталась

БД на BYPASSING BUFFER не проведешь

P. S.
а что случилось с классическими способами? сапера гонять, пинговать сеть, плевать на вентилятор в конце концов

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

2 zsap: как мне кажется, наличие искомой записи - как раз влияет. Приведенная вами оценка O - это грубо говоря оценка "сверху" (пруф, извините, что в вики). В лучшем случае, информация будет найдена по кратчайшему маршруту (в неком "среднем" случае, инфа будет так же найдена по оценке O(ln(N)), одно из свойств B-tree, которые и используются для построения индексов в популярных СУБД).

Тогда уж лучше не на 1, а использовать псевдослучайные числа потому что с высокой вероятностью следующий номер материала окажется в том же блоке данных, который уже закеширован на уровне БД