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

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

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

Скорость работы запроса, и количество полей в таблице

partizan © (2006-07-26 12:08:00)
Влияет-ли на скорость запроса количество полей в таблице.
То-есть если в запросе учавствуют только 5 полей, но в таблице есть еще куча, не замедляет-ли это запрос?

Может имеет смысл те поля, которые редко учавствуют в запросе вынести в отдельную таблицу и join-ить ее по мере надобности?

(работаю с postgre)

Desdechado (2006-07-26 16:23:00) [1]

> забывая, что есть дороги с односторониим движением
Но помятуя о том, что безбашенных на мотоциклах много, которых гоняют против движения :)

Sergey13 (2006-07-26 16:14:00) [2]
> [16] Desdechado © (26.07.06 15:53)

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

Desdechado (2006-07-26 15:53:00) [3]
> Тут никакой зависимости нет
Есть :)
В нормализованных таблицах эта закономерность хорошо прослеживается.
Понятно, что есть и отклонения от нее, но они только подтверждают зависимость.

Sergey13 (2006-07-26 15:47:00) [4]
2 [14] Desdechado © (26.07.06 15:42)
> Это верно. Но также верно и то, что чем шире таблица, тем
> меньше полей в ней имеют атрибут NOT NULL.

С чего бы это? Тут никакой зависимости нет. И в 5 полях 4 могут быть нулами, и в 100 могут быть все нот нулл. Это как повезет.

Desdechado (2006-07-26 15:42:00) [5]
Sergey13 © (26.07.06 15:23) [13]
> Чем шире таблица
Это верно. Но также верно и то, что чем шире таблица, тем меньше полей в ней имеют атрибут NOT NULL. А NULL-значения не хранятся, т.е. места не занимают.

Sergey13 (2006-07-26 15:23:00) [6]
Чем шире таблица, тем меньше записей помещается в блоке данных на диске. Сервер читает блоками, а не полями. Следовательно, чем шире таблица, тем большее количество операций чтения надо сделать.
Это рассуждения "вообще", а не конкретно по постгре (не юзал).

Desdechado (2006-07-26 15:19:00) [7]
судя по ID - это PK
нормальный сервер в случае COUNT использует индекс по этому PK, не читая таблиц

partizan (2006-07-26 15:12:00) [8]
Проверил на практике (posgreSQL)
В 1-й тадлице было 6 полей, во 2-й 31, все инт4, количество записей - одинаковое.

Запрос SELECT count(id) FROM ... выполняется для 2-й таблице на 66% дольше

partizan (2006-07-26 12:45:00) [9]
Нужно еще быстрее

ЮЮ (2006-07-26 12:39:00) [10]
Если в таблице много записей и вопрос выполнтся быстро, откуда такой философский вопрос? :)

Desdechado (2006-07-26 12:38:00) [11]
Конкретный вопрос про то, как конкретный сервер обрабатывает конкретные таблицы, можно узнать у производителя сервера или (если открыты исходники) посмотреть там, а не гадать на гуще "читаем блок-забываем блок".

partizan (2006-07-26 12:34:00) [12]
Я же не написал "У меня очень долго работает запрос - помогите". Я задал конкретный вопрос

partizan (2006-07-26 12:31:00) [13]
Да есть индексы, и нормализовано. Но в таблице МНОГО записей

Desdechado (2006-07-26 12:27:00) [14]
Не там проблемы ищешь. Нормализуйся и схему данных нормализуй.

ЮЮ (2006-07-26 12:24:00) [15]

> подгружает часть таблицы в ОП, просматривает ее,

И чего он та ищет? Может индексы по полям, участвующим в WHERE (если она в твоем запросе есть), лучше создать, чтобы она меньше там всего просматривала?

partizan (2006-07-26 12:17:00) [16]

> и среди них нет BLOB-ов, то, скорей всего, - нет

А чем принципиально отлючаются поля с BLOB-ами от обычных? Большим размером?

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

Max Zyuzin (2006-07-26 12:12:00) [17]
>partizan (26.07.06 12:08)
Имеет смысл нормализовать таблицы и настроить индексы, а не выносить все подряд

ЮЮ (2006-07-26 12:11:00) [18]
Если
SELECT *
то естественно влияет

Если
Select f1, f2, f3, f4, f5

и среди них нет BLOB-ов, то, скорей всего, - нет

Наверх

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