индекс на вторичном ключе, зачем он нужен? секретные материалы архитектора СУБД

добавлено: 13 мар 17
понравилось:0
просмотров: 362
комментов: 5

теги:

Автор: Myp3_u_K

проще всего разобраться в этом на примерах
создадим две таблицы

create table tsp(n number primary key); 
-- заполним таблицу данными
insert into tsp
select level from dual connect by level < 100001;

-- создадим вторую таблицу

create table ts(n number primary key, m number, CONSTRAINT fk_ts
    FOREIGN KEY (m)
    REFERENCES tsp(n));

для этой таблицы существует вторичный ключ от m на поле n таблицы tsp
заполним таблицу ts данными
insert into ts(n,m)
select level,mod(level,90000)+1 from dual connect by level < 1000000;

-- попытаемся удалить строки из этой таблицы
delete tsp where n > 99000

-- операция выполнялась 112 секунд

создадим индекс на поле m таблицы ts
create index ts_idx on ts(m);

-- повторим операцию удаления
delete tsp where n > 93000

-- 0,45 секунды

Почему это произошло?
СУБД была вынуждена проверять наличие связанных записей в таблице ts при удалении данных из таблицы tsp
При проектировании архитектуры, следует учитывать такие особенности, особенно при работе с большими таблицами,
так как, именно такие недочеты,
приводят к существенному снижению производительности системы

Комментарии


  • Тот же mysql автоматически создает индекс при добавлении FK

  • он там не всегда нужен на самом деле - в больших таблицах
    в таблицах где массовые операции удаления, да нужен
    но, допустим, 10 связанных таблиц по 100-500 строчек, нужны там индексы ,нет наверное и индексы разные бывают, по ситуации вообщем...

  • Есть мнение, что на гигантских таблиц FK скорее вредны, чем полезны, и что ради скорости можно пожертвовать целостностью данных.

  • Важен баланс , в некоторых случаях действительно можно обойтись и без FK
    таблица логов транзакций, таблица NF трафика, поминутный билинг

  • Блокировки, же. Читайте Тома Кайта.



Необходимо войти на сайт, чтобы оставлять комментарии