Каморка

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

1. При грамотных индексах все будет шуршать довольно быстро.
2. Создать еще одну таблицу в которую засунуть редко используемые поля.
3. Сгруппировать записи и создать несколько таблиц каждая из которых будет иметь минимальное количество пустых полей. Такая возможность есть, но как быстро при этом будет работать выборка из нескольких таблиц?

2+3+experiment+profile

[trn]
Dostatochno ne malovazhno, kakaya RDBMS ispol'zuetsya.
orakl - naprimer po null-am ne sozdaet index entries, informiks - sozdaet.
db2 - ne pomnyu, no vrode-bi net.
Format hraneniya tozhe sil'no zavisit ot konkretnoi RDBMS. teoreticheski esli v orakle vse null-like polya zabrosit' v hvost, to vliyanie na razmer tablici budet nebol'shim.


"redko ispol'zuyutsya" - ne selektyatsya, ili ne zapolnyayutsya?
esli poslednee, to IMHO pol'zi ot razdvoeniya tablici odin-k-odnomu budet nemnogo. lishnie 3-4 logikal reads na poisk po klyuchyu i access po onomu.

[/trn]

Nowadays таблица в 1 миллион это ерунда. Я полагаю ты выполняешь SELECT statement с WHERE clause.

Однозначно 1 опция. Consider using covering indexes

He's got a large table with some unused columns. You are suggesting something, that will blow up the table size even more, despite the fact that highly non-unique indices are inefficient.

Yuri Dimant писал(а):Nowadays таблица в 1 миллион это ерунда. Я полагаю ты выполняешь SELECT statement с WHERE clause.

Однозначно 1 опция. Consider using covering indexes

Melnik
I did not uderstand your point. If he has a properly defined indexes on the colums that means the query optimizer will be able to create an efficient execution plan so that speeds up the query. My point was to exclude "unused" column/s from SELECT.

hawk писал(а):[trn]
"redko ispol'zuyutsya" - ne selektyatsya, ili ne zapolnyayutsya?
esli poslednee, to IMHO pol'zi ot razdvoeniya tablici odin-k-odnomu budet nemnogo. lishnie 3-4 logikal reads na poisk po klyuchyu i access po onomu.

[/trn]

[trn]
Ne zapolnyajutsya. Indeksov po wtim polyam net, tak kak selekt po nim vypolnyaetsya krajne redko i ne kritichen po vremeni.

Vsego polej okolo 30; redko ispol'zuemye - prakticheski vse celye, ne [/trn] varchar.

StS: можешь показать схему, запросы и тип базы? можно в приват.

StS писал(а):Есть таблица в которой миллион записей. Треть полей заполнено всегда, но остальные используются крайне редко. Время селекта из таблицы критично. Какие будут соображения по оптимизации селекта?

1. При грамотных индексах все будет шуршать довольно быстро.
2. Создать еще одну таблицу в которую засунуть редко используемые поля.
3. Сгруппировать записи и создать несколько таблиц каждая из которых будет иметь минимальное количество пустых полей. Такая возможность есть, но как быстро при этом будет работать выборка из нескольких таблиц?

Пункт первый. Не вижу причин городить огород с пунктами 2 или 3. Единственоое но - при наличии большого количества индексов возможна значительная потеря производительности на insert/update (overindexing). В этом случае действительно будет лучше разбить таблицу на несколько. И миллион записей - это ничто для современной базы. Вот ежели б там был миллиард... Да и тогда пункт первый.

[trn]Klassicheskij sluchaj [/trn] transaction history.
http://4test.at.tut.by/Transaction.jpg
[trn]Wto ne vse polya, budut esche, no ne obyazatel'nye.[/trn]

[trn]Vsegda zapolneny polya[/trn] ID, DateTime, AccountID, Amount, TransactionCodeID, SequenceNumber [trn] i libo [/trn] ProgramID, [trn]libo[/trn] EmployeeID.

Select [trn]delaetsya v osnovnom po [/trn]AccountID and Date ([trn]Kstati, budet li luchshe raznesti[/trn] DateTime[trn] v raznye polya?).
Wto naibolee chastyj selekt i vremya otveta nuzhno minimizirovat'. Dlya nekotoryh selektov, tipa[/trn] WHERE TransactionCode=1234[trn] indeksy tozhe prigodyatsya, a vot pri zaprose "kto perevel tri milliona na Bagamy" mozhno i podozhdat' paru minut.[/trn]

StS писал(а):[trn]Klassicheskij sluchaj [/trn] transaction history.
http://4test.at.tut.by/Transaction.jpg
[trn]Wto ne vse polya, budut esche, no ne obyazatel'nye.[/trn]

[trn]Vsegda zapolneny polya[/trn] ID, DateTime, AccountID, Amount, TransactionCodeID, SequenceNumber [trn] i libo [/trn] ProgramID, [trn]libo[/trn] EmployeeID.

Select [trn]delaetsya v osnovnom po [/trn]AccountID and Date ([trn]Kstati, budet li luchshe raznesti[/trn] DateTime[trn] v raznye polya?).
Wto naibolee chastyj selekt i vremya otveta nuzhno minimizirovat'. Dlya nekotoryh selektov, tipa[/trn] WHERE TransactionCode=1234[trn] indeksy tozhe prigodyatsya, a vot pri zaprose "kto perevel tri milliona na Bagamy" mozhno i podozhdat' paru minut.[/trn]

А база то какая?

StS писал(а):[trn]Klassicheskij sluchaj [/trn] transaction history.
http://4test.at.tut.by/Transaction.jpg
[trn]Wto ne vse polya, budut esche, no ne obyazatel'nye.[/trn]

[trn]Vsegda zapolneny polya[/trn] ID, DateTime, AccountID, Amount, TransactionCodeID, SequenceNumber [trn] i libo [/trn] ProgramID, [trn]libo[/trn] EmployeeID.

Select [trn]delaetsya v osnovnom po [/trn]AccountID and Date ([trn]Kstati, budet li luchshe raznesti[/trn] DateTime[trn] v raznye polya?).
Wto naibolee chastyj selekt i vremya otveta nuzhno minimizirovat'. Dlya nekotoryh selektov, tipa[/trn] WHERE TransactionCode=1234[trn] indeksy tozhe prigodyatsya, a vot pri zaprose "kto perevel tri milliona na Bagamy" mozhno i podozhdat' paru minut.[/trn]

А вообще по любому - два индекса по AcciuntId and Date. И все дела. Далее можно экспериментровать добавляя индексы и удаляя их ежели это создает проблемы.

А база то какая?

[trn]Ne hotelos' by privyazyvat'sya k konkretnoj baze. Budet [/trn]PostgreSQL or MySQL[trn] - chto-to deshevoe/besplatnoe.

[/trn]DateTime[trn] raznosit' na dva polya [/trn]Date and Time[trn] odnoznachno?[/trn]

StS писал(а):

А база то какая?

[trn]Ne hotelos' by privyazyvat'sya k konkretnoj baze. Budet [/trn]PostgreSQL or MySQL[trn] - chto-to deshevoe/besplatnoe.

[/trn]DateTime[trn] raznosit' na dva polya [/trn]Date and Time[trn] odnoznachno?[/trn]

В таком случае - лучше разнести. Тогда получится три индекса и три поля. В противном случае можно попасть на вычисления/конвертацию а это в бесплатных базах бывает кисло устроено.

Thanks, Vovchik