Я в замешательстве от предпоследнего слайда.

Допустим, у меня таблица Docs с 5.000.000 записями, и мне надо загрузить 500 докуметов с известными ключами.

Я просто делаю select * from Docs where DocId in (123,124,145,148, ... )
И всё моментально грузится.

Если последовать совету и переписать на where DocId+0 in (...)
станет всё очень медленно и печально.

kdvВ основном field in (...) используют с неуникальными индексами, о чём я и говорил
Спасибо, теперь стало понятнее.
Также это, возможно, объясняет явление, что join по primary key намного быстрее, чем по другому индексированному полю таблицы.

Я никак не мог этого понять, думал, что в обоих случаях используется одинаковый поиск по ключу в индексе.

Ivan_PisarevskyОпять таки, если у тебя так много известных ИДов, то можно очень легко натолкнуться на ограничение по длине запроса. а если не 500, скажем 5000?
разбиваю на блоки по 500

Ivan_PisarevskyСдается мне дешевле будет ИДы влить в ГТТ табличку и сджойниться с ней, чем писать ин.
тут проблема будет передать 500 инсертов, это очень медленно.
всё никак не дождусь, когда сделают bulk insert

Гаджимурадов Рустамunah> явление, что join по primary key намного быстрее, чем по другому индексированному полю таблицы.

Ась? Это откуда ?

Из жизни.
Вот пример:


заливаем 700 записей в Shops, и 5.000.000 в Orders.
Теперь сравниваем скорость


и

Симонов ДенисВо-вторых сравнивать надо


это понятно, что всё надо фетчить.

сейчас сравнил все варианты на тестовом сервере.

join по primary key - быстрее

PLAN JOIN (O NATURAL, S INDEX (PK_SHOPS))

------ Performance info ------
Prepare time = 15ms
Execute time = 16s 224ms
Avg fetch time = 16 224,00 ms
Current memory = 147 808 712
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 75 685
Writes from cache to disk = 17
Fetches from cache = 0

чем так

PLAN JOIN (S NATURAL, O INDEX (FK_ORDER_REF_SHOP))

------ Performance info ------
Prepare time = 16ms
Execute time = 19s 640ms
Avg fetch time = 19 640,00 ms
Current memory = 147 734 296
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 1 672 411
Writes from cache to disk = 28
Fetches from cache = 0

И внимание на кол-во страниц, это очень важно. Под нагрузкой время будет отличаться намного сильнее.

Хеш-join вне конкуренции (новость тройки? я его как-то упустил из виду)

PLAN HASH (O NATURAL, S NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 6s 615ms
Avg fetch time = 6 615,00 ms
Current memory = 147 732 704
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 75 433
Writes from cache to disk = 8
Fetches from cache = 0

Ivan_PisarevskyКлиент же каким-то образом раздобыл себе списки ключей, сдается мне, что он вычитал оные с сервера, а не придумал сам.

Откуда берутся эти списки ИДов?
Разные случаи.

Самое простое - загрузка (или любая другая операция) с большим списком сущностей, по которой юзер хочет видеть прогресс.
Тогда первый запрос select Id from ... join ....
узнаём, сколько всего будет строк в результате, а потом выполняем операцию (грузим на клиент) пачками по 100-1000.

Особенно актуально, если клиент подключен не БД, а к серверу приложений по HTTP и на каждый запрос у клиента лимит по времени и размеру пакета.


Был ещё вариант использования FB как тупое key-value хранилище.

Применялось ручное управление кешированием в сервере приложений.
Все join-ы делаются в памяти, а строки грузятся по списку Id, только те, которых ещё нет в памяти инстанса. Сильно экономит кол-во чтений из БД.

И напоследок. Отношения многие-ко-многим.
Мастер-сущность в таблице с 30 млн. записей, Detail - 3 млн. записей и линков между ними - более 300 млн (отдельная таблица со ссылками на master и detail для каждой связи, всё по лучшим практикам).
И вот как раз join к таблице links стал захлёбываться (потому что не по unique index?).

Последователи чистой реляционной теории могут плеваться, но факт есть факт.
После переноса links в таблицу master тупо в строковое поле varchar(3000) id-шники через запятую, и чтением details по списку Id (where DetailId in (121,122,123,...)) нагрузка настолько уменьшилась, что система была спасена.

Старый плюшевый мишкаЯ тебе один умный вещь скажу, только ты не обижайся пожалуйста (С)У вас опыт слишком ограничен, а мне обижаться? ;)

Симонов ДенисНу и буфер Memory buffers = 2 048 для троечного SS это просто смех.
Проверил на другом сервере

PLAN JOIN (O NATURAL, S INDEX (PK_SHOPS))
Memory buffers = 4 194 304
Reads from disk to cache = 120


PLAN JOIN (S NATURAL, O INDEX (FK_ORDER_REF_SHOP))
Memory buffers = 4 194 304
Reads from disk to cache = 914


Похоже это не бага с огромным кол-вом чтений при таких join-ах.
Просто надо buffers поднимать ))) Кто-ж знал )))

hvlad,

у меня было хорошо воспроизводимое наблюдение:

- если добавлять в запрос join-ы по primary key, никаких проблем можно не ждать

- есть добавлять в запрос join-ы по другим индексам, может резко вырасти кол-во чтений страниц, и такими join-ами надо всё 100 раз проверить.

Хорошо, что в этой теме более-менее разобрали причину.