Внешний ключ автоматически создает индекс?
Ваши команды python и shell не идентичны: в команде shell вы указываете пределы soft, а в python вы указываете пределы hard. Синтаксис для аргумента командного флага --ulimit таков:
=[:]
И в документации объясняется:
Примечание. Если вы не предоставите жесткий предел, мягкий предел будет использоваться для обоих значений. Если ulimits не установлены, они будут унаследованы от ulimits по умолчанию, установленных на демоне.
blockquote>Чтобы получить идентичное поведение, я бы попытался изменить ваши объявления ulimit python на
docker.types.Ulimit(name='stack', soft=67108864, hard=67108864)]Это звучит как недостаток документации по python , в которой говорится только что
softиhardявляются необязательными аргументами.
7 ответов
Внешний ключ - это ограничение, связь между двумя таблицами, которая не имеет ничего общего с индексом как таковым.
Но это известный факт, что это имеет большой смысл для индексации всех столбцов, которые являются частью любого отношения внешнего ключа, потому что через FK-отношение вам часто нужно искать связанную таблицу и извлекать определенные строки на основе одного значения или диапазона значений.
Итак. имеет смысл индексировать любые столбцы, участвующие в FK, но FK как таковой не является индексом.
Посмотрите прекрасную статью Кимберли Триппа «Когда SQL Server перестал помещать индексы в столбцы внешнего ключа?» .
Насколько мне известно, нет. Внешний ключ только добавляет ограничение, что значение в дочернем ключе также должно быть представлено где-нибудь в родительском столбце. Он не сообщает базе данных, что дочерний ключ также необходимо проиндексировать, только с ограничениями.
SQL Server автоматически создает индексы для первичных ключей, но не для внешних ключей. Создайте индекс для внешних ключей. Вероятно, это стоит накладных расходов.
Нет, неявного индекса для полей внешнего ключа нет, иначе почему бы Microsoft сказала «Создание индекса для внешний ключ часто бывает полезен ». Ваш коллега может перепутать поле внешнего ключа в ссылающейся таблице с первичным ключом в указанной таблице - первичные ключи действительно создают неявный индекс.
Вау, ответы повсюду. Итак, в Документации говорится:
Ограничение FOREIGN KEY является кандидатом на индекс, потому что:
Изменения в ограничениях PRIMARY KEY проверяются с помощью ограничений FOREIGN KEY в связанных таблицах.
Столбцы внешнего ключа часто используются в критериях соединения, когда данные из связанных таблиц объединяются в запросы путем сопоставления столбца (столбцов) в ограничении FOREIGN KEY одной таблицы с столбцами первичного или уникального ключа в другой таблице. Индекс позволяет Microsoft® SQL Server ™ 2000 быстро находить связанные данные в таблице внешнего ключа. Однако создание этого индекса не является обязательным.
Допустим, у вас есть большая таблица заказов и маленькая таблица клиентов. Есть внешний ключ от заказа к покупателю. Теперь, если вы удаляете клиента, Sql Server должен проверить, нет ли сиротских заказов; если есть, то возникает ошибка.
Чтобы проверить, есть ли какие-либо заказы, Sql Server должен выполнить поиск в таблице больших заказов. Теперь, если есть индекс, поиск будет быстрым; в противном случае поиск будет медленным.
Таким образом, в этом случае медленное удаление можно объяснить отсутствием индекса. Особенно, если Sql Server должен будет искать 15 больших таблиц без индекса.
PS Если внешний ключ имеет ON DELETE CASCADE, Sql Server все равно должен искать таблицу заказов,
Строго говоря, внешние ключи не имеют абсолютно ничего общего с индексами, да. Но, как указали ораторы выше меня, имеет смысл создать его, чтобы ускорить поиск FK. Фактически, в MySQL, если вы не укажете индекс в объявлении FK, движок (InnoDB) создаст его автоматически.