Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Скорость выборки

Страницы: < 1 2 3 4 5 6 >
Piter © (2004-12-18 18:50:00)
Есть такое выражение:

'SELECT Count(n) From MyTable Where n=0'

Выборка длится около 4 секунд :(
Всего записей в базе 4700.

Почему так медленно? Правда, стоит заметить, что это только первый раз так долго. Потом такие выражения выполняются не более 100 мс, но все равно - загрузка программы происходит очень долго из-за этого.

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

Можно как-нибудь ускорить процесс? А то 4 секунды - это перебор все таки, имхо, на Athlon 1800. Не понимаю, как тогда работают базы с миллионами записей...

Использую базу Firebird Embedded

Piter (2004-12-21 00:11:00) [21]
AlterEgo of WondeRu © (20.12.04 23:47) [89]
with Query2 do
begin
Close;
SQL.Clear;
SQL.Add('select * from answers where n=0');
Open;
RCount := RecordCount; //то что нада
end;

и типа сам то как думаешь - какой ответ получится если проверять RecordCount?

AlterEgo of WondeRu (2004-12-20 23:47:00) [22]
AlterEgo of WondeRu © (20.12.04 23:39) [88]
with Query2 do begin Close; SQL.Clear; SQL.Add('select * from answers where n=0'); Open; RCount := RecordCount; //то что нада end;

AlterEgo of WondeRu (2004-12-20 23:39:00) [23]
Piter © (20.12.04 22:59) [87]
Более того, я это уже писал в самом начале, так что вместо того, чтобы допрашивать можно хотя бы чуть чуть почитать, что я пишу. Я писал, что SELECT * выполняется очень быстро. И если даже выполнить Count * ПОСЛЕ Select * - то все равно 4 секунды...
У вас не так?
как ни странно... читал каждый пост!
может я не понимаю тебя, но не нада искать причину, делай так как работает!
нефиг делать count(*), делай select * from answers where n=0, а затем в Query (если конечно его используешь) проверяй свойство RecordCount!!!

Piter (2004-12-20 22:59:00) [24]
AlterEgo of WondeRu © (20.12.04 21:21) [83]
это первый селект из таблицы?

естественно! Я что, такой дурак, чтобы всем талдычить про первый запуск, а самому делать по другому?

Более того, я это уже писал в самом начале, так что вместо того, чтобы допрашивать можно хотя бы чуть чуть почитать, что я пишу. Я писал, что SELECT * выполняется очень быстро. И если даже выполнить Count * ПОСЛЕ Select * - то все равно 4 секунды...
У вас не так?

Sergey_Masloff (20.12.04 21:29) [86]
поле NOT NULL поправляя запись домена

а в этом месте можно поподробнее?

Sergey_Masloff (20.12.04 21:29) [86]
и потом объявляешь что это поле PK

а как объявить существующие поле, что оно PK?

Sergey_Masloff (2004-12-20 21:29:00) [25]
Стоп... у тебя есть BLOB-ы. Не катит

Тогда так: добавляешь поле, заполняешь уникальными значениями, делаешь по нему уникальный индекс, делаешь поле NOT NULL поправляя запись домена и потом объявляешь что это поле PK. Должно прокатить.

Sergey_Masloff (2004-12-20 21:26:00) [26]
Когда писал не видел
Piter © (20.12.04 21:16) [81]

К существующей базе добавить можно но чревато опасностями. Прще так: берешь скрипт таблицы и создаешь вторую такую же по структуре.

1) Делаешь INSERT INTO TABLE2 SELECT * FROM TABLE
2) Делаешь DELETE FROM TABLE
3) Добавляешь 1 поле ID INTEGER NOT NULL
4) Добавляешь триггер бифор инсерт
IF (NEW.ID IS NULL) THEN NEW.ID = GEN_ID(YOURGENERATORNAME,1);
5) Объявляешь PRIMARY KEY(ID);
6) Делаешь INSERT INTO TABLE(FIELD1,...FIELDN)
SELECT FIELD1,...FIELDN FROM TABLE2
7) Делаешь DROP TABLE2

Все в твоей TABLE есть ПК.

AlterEgo of WondeRu (2004-12-20 21:24:00) [27]
Anatoly Podgoretsky © (20.12.04 21:04) [79]
теперь я допрашиваю)

AlterEgo of WondeRu (2004-12-20 21:21:00) [28]
Piter © (20.12.04 21:08) [80]
А вот SELECT * происходит практически мгновенно.
это первый селект из таблицы?

Sergey_Masloff (2004-12-20 21:19:00) [29]
Piter © (20.12.04 21:08) [80]
>Попробуй таблицу, которую использовал Sniknik и я.
Мои сообщения Sergey_Masloff (20.12.04 09:19) [66]
относятся К ТВОЕЙ структуре таблицы. В одном случае я добавил к ней еще одно поле и заполнил его уникальными значениями пометив как PK. В таблице 6700 записей, до 10 тыс могу конечно набросить но сначала
СДЕЛАЙ PK И НАПИШИ РЕЗУЛЬТАТ ТЕСТА!!!! ;-)))

Piter (2004-12-20 21:16:00) [30]
Sergey_Masloff (20.12.04 20:56) [78]
Создать первичный ключ пробовал? Как результат?

да, создавал. Ускорение, конечно, есть, но хочется еще быстрее...

А можно как-нибудь добавить к существующей базе поле с Primary Key?
Неужели придется переносить записи...

Piter (2004-12-20 21:08:00) [31]
sniknik © (20.12.04 1:12) [63]
задержка на первом есть, но не 4 сек, это точно

ну на тестовой таблице у меня тоже не 4 секунды, а меньше, около секунды. На реальной 4 секунды, но там полей больше.

sniknik © (20.12.04 1:12) [63]
первый запуск предложенного селекта с count(*) около сек. (0,73 показало) второй 0,06.

и у меня тоже самое. Только не 0,73 - а ближе к секунде

при добавленом индексе время меньше но не намного

аналогично

Sergey_Masloff (20.12.04 9:19) [66]
Prepare time = 0ms
Execute time = 125ms

даже учитывая, что таблицы без ПК - поразительные результаты... Может, у тебя таблица не как у меня? Сделай таблицу точно такой структуры как я написал. И заполни ее 10.000 записями по алгоритму программы, которую я выложил.

Sergey_Masloff (20.12.04 17:03) [74]
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах?

почему же? У Sniknik очень похожие результаты. А вот твои результаты мне нравятся гораздо больше, если бы у меня так было... но мне просто кажется, что ты экспериментируешь на другой таблице, более простой для подсчета. Попробуй таблицу, которую использовал Sniknik и я.

Alexander Panov © (20.12.04 16:52) [73]
При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск

несомненно. Вопрос в другом - почему первый раз так долго?

sniknik © (20.12.04 1:12) [63]
странно, у меня count работает на порядок быстрее чем полный селект. (так и должно в приципе)

а попробуй еще раз - мне кажется ты ошибся. Ибо даже на SQL.ru писали, что count(*) поднимает всю таблицу и кеширует ее.

По крайней мере, у меня первый count(*) на тестовой таблице длится секунду. На реально - четыре секунды.
А вот SELECT * происходит практически мгновенно.

Anatoly Podgoretsky (2004-12-20 21:04:00) [32]
Допрос продолжается :-)

Sergey_Masloff (2004-12-20 20:56:00) [33]
Piter ©
Создать первичный ключ пробовал? Как результат?

AlterEgo of WondeRu (2004-12-20 20:22:00) [34]
Piter © (20.12.04 20:07) [76]
типа это быстрей отработает? Фигня, не может быть такого...
не я же сказал: "А то просто второй вариант и у меня быстро отрабатывает. А вот count...
"

Piter (2004-12-20 20:07:00) [35]
AlterEgo of WondeRu © (20.12.04 0:25) [60]
чего голову морочишь? делай просто селект и проверяй Query1.RecordCount!

типа это быстрей отработает? Фигня, не может быть такого...

Alexander Panov (2004-12-20 19:26:00) [36]
Sergey_Masloff (20.12.04 17:03) [74]
Файловый кэш ИМХО примерно одинаково работает везде.

В разных системах по-разному, все-таки.
Еще надо учесть наличие других работающих программ в данный момент, использование ими памяти. от настроек системы тоже зависит.

Т.е. в точности повторить эксперимент не удастся.

Если только на голой системе.

Sergey_Masloff (2004-12-20 17:03:00) [37]
Alexander Panov © (20.12.04 16:52) [73]
>Не хотел говорить свое мнение, но думаю, что здесь не последнюю >роль играет системный файловый кэш.
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах? Файловый кэш ИМХО примерно одинаково работает везде. Заявляемых пациентом ;-) 3-4 секунд повторить не удалось. Причем не поднимается же весь файл в кеш - только определенные страницы. А вот почему при такой же таблице у Piter нужно больше страниц в памяти - мы и обсуждаем.
Сам Piter молчит. Заведение PK помогло или нет - вот в чем вопрос! ;-)

Alexander Panov (2004-12-20 16:52:00) [38]
Не хотел говорить свое мнение, но думаю, что здесь не последнюю роль играет системный файловый кэш.

При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск.
Это же может происходить при

Piter © (19.12.04 18:55) [53]

...И только после перезагрузки в первый раз опять все медленно. Или можно не после перезагрузки - а например после интенсивной игры в какой-нибудь Call Of Duty. Тогда после выхода из игры опять выборка будет медленной в первый раз (видимо, ОС из-за игры убирает из кеша данные сервера)...

Мое мнение такое...

msguns (2004-12-20 16:30:00) [39]
Вопрос к Piter: а что там у нас с антивирусниками ? Какой (какие) стоЯт ?
У меня стоИт Касперский. Так к тормозам при первом обращении к серверу я привык в общем-то..;(

Sergey_Masloff (2004-12-20 15:51:00) [40]
jack128 © (20.12.04 11:48) [68]
>Нефига не понимаю. PLAN (

Нам надо перебрать всю таблицу. Ее записи разбросаны по разным (непоследовательным) страницам IB. Теоретически серверу нужно было бы перебрать ВСЕ страницы данных и смотреть по каждой записи не из нужной ли она таблицы. Это небыстро если в базе не одна таблица.
Поэтому NATURAL это проход по индексу первичного ключа с последующими быстрыми обращениями к уже известным страницам данных с нужными записями.
Так как тут ПК нет IB наверняка сроит индекс и боюсь что по всем полям сразу что конечно тоже скорости не добавляет. Конечно на 100% я это не знаю но предположение это с высокой степенью достоверности.
Кстати смотри - у Piter база около 25 мег у меня едва 3 (тольк тестовые таблицы в основном). У него первая выборка 3-4 секунды у меня гораздо меньше но все же больше последующих. Тоже ведь укладывается в теорию.

Страницы: < 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »