Индекс для внешнего ключа таблицы БД.md
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Struchkov Mark 2024-10-16 11:15:02 +03:00
parent 6b9c2a1f15
commit 51c5bf2961
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
2 changed files with 13 additions and 7 deletions

View File

@ -7,21 +7,29 @@ zero-link:
parents:
linked:
---
При создании внешнего ключа в базе данных важно не забывать добавлять индекс на связанный столбец.
При создании внешнего ключа в базе данных важно не забывать про добавление индекса на соответствующий столбец. Разберёмся, почему это важно.
Внешний ключ обеспечивает связь между двумя таблицами, гарантируя, что значения в одном столбце соответствуют значениям в другой таблице. ==При выполнении операций, таких как SELECT, UPDATE или DELETE, СУБД должна проверить целостность данных. Без индекса проверка становится затратной по времени, так как приходится сканировать всю таблицу для поиска нужных записей==. Индекс решает эту проблему, значительно ускоряя поиск и проверку данных.
Сперва обратимся к [документации PostgreSQL](https://www.postgresql.org/docs/current/ddl-constraints.html):
Рассмотрим пример, где мы удаляем строку из таблицы, у которой есть связь с другой таблицей.
> A foreign key must reference columns that either are a primary key or form a unique constraint, or are columns from a non-partial unique index. This means that the referenced columns always have an index to allow efficient lookups on whether a referencing row has a match. Since a `DELETE` of a row from the referenced table or an `UPDATE` of a referenced column will require a scan of the referencing table for rows matching the old value, ==it is often a good idea to index the referencing columns too==. Because this is not always needed, and there are many choices available on how to index, the declaration of a foreign key constraint does not automatically create an index on the referencing columns.
Когда выполняются операции, такие как SELECT, UPDATE или DELETE, СУБД должна проверять целостность данных. Без индекса проверка связей может занимать много времени, поскольку требуется сканирование всей таблицы для поиска необходимых записей.
Рассмотрим пример удаления строки из таблицы, связанной с другой таблицей через внешний ключ. ==Удаление выполняется по первичному ключу, и внешний ключ в запросе напрямую не используется.==
![600](../../meta/files/images/Pasted%20image%2020240331093028.png)
Поиск записи в таблице происходит быстро, так как удаление выполняется по первичному ключу. Однако, у нас есть связь с другой таблицей, и ==самый долгий этап это проверка связей с этой таблицей.==
Видно, что поиск по первичному ключу выполняется быстро, так как удаление производится по индексированному первичному ключу. Однако ==наибольшее время занимает проверка связей с другой таблицей.==
Добавим индекс на внешний ключ и проведем повторный эксперимент.
![600](../../meta/files/images/Pasted%20image%2020240331093524.png)
Мы получили ускорение в 2055 раз!
После добавления индекса на внешний ключ и повторного выполнения запроса:
- Без индекса на внешний ключ операция удаления заняла 690 мс.
- С индексом — всего 0.101 мс.
Таким образом, ==в большинстве случаев стоит создавать индекс для внешнего ключа, особенно если часто выполняются операции удаления или обновления==. Но когда индекс не нужен? ==Если в основном таблица используется для операций INSERT и SELECT, индекс на внешний ключ может не понадобиться==.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Базы Данных|00 Базы Данных]]

View File

@ -6,8 +6,6 @@ zero-link:
title: Java разработка
---
- [Устройство Java](Устройство%20Java.md)
- [JDK](../../dev/java/JDK.md)
- [[../../dev/java/Java Reflection|Java Reflection]]
- [[../../dev/java/Многопоточность в Java|Многопоточность в Java]]
- Системы сборки
- [Maven](00%20Maven.md)