У меня есть первичный ключ на (A, B), где A является INT и B является INT. Будет ли поиск запросов по A быстрее, если бы у меня был индекс на A?Является ли индекс с несколькими столбцами медленнее, чем индекс с одним столбцом?
Я понимаю крайнее левое префиксное правило, но мне любопытно, если многоколоночный ключ/индекс работает хуже одного столбца/индекса из-за того, что ключ длиннее.
В некоторых случаях он может выполнять хуже - если остальные столбцы являются большими, например: A: INT, B: VARCHAR (128), C: текст индекс А будет работать лучше, чем индекс по , B, C
В большинстве случаев он выполняет то же самое; в вашем случае у вас есть 4 против 8 байт, поэтому накладные расходы на наличие второго индекса не стоит этого делать.
Помните, что первичный ключ работает лучше, чем вторичный индекс, особенно если движок хранения - InnoDB (первичный ключ - это индекс кластеризации), и это не запрос покрытия (ему нужно получить доступ к таблице для загрузки данных, а не хранится в индексе)
На самом деле в InnoDB все вторичные индексы содержат первичный ключ, поэтому по умолчанию они больше, чем PK.
Я вижу. Я проверил таблицу и понял, что оба столбца INT, поэтому я пересмотрел свой пост. Очень полезно знать, что первичный ключ работает лучше, чем индекс, спасибо! – ktm5124
У вас есть ситуация, когда составной ключ имеет два компонента. Первый - 4 байта, а второй - 4 байта. Общий ключ - 8 байтов.
Индекс первичного ключа сгруппирован, что означает, что «листы» b-дерева являются самими фактическими записями. Кластеризованный индекс будет быстрее получать доступ к другим типам индексов.
Одним из показателей эффективности индекса является размер ключа (а также дополнительные столбцы, хранящиеся в индексе). Индекс с 4-байтным ключом будет меньше индекса с 8-байтовым ключом. Это означает меньшее использование диска и меньшее количество памяти в памяти. Однако выгоды здесь могут быть довольно маленькими. В конце концов, миллион строк в таблице будет соответствовать не более 10-20 миллионов байт (индексы имеют дополнительные накладные расходы в них).
Еще одно соображение - это выполнение шагов модификации данных. В кластерном индексе вставка/изменение значения ключа в середине таблицы требует повторной записи самих записей. Тем не менее, вы сомневаетесь, что это не изменение адресных данных.
Если вы уже определили индекс первичного ключа, то добавление другого индекса - дополнительные накладные расходы для системы. Вы можете обнаружить, что индексы занимают память, поэтому вместо экономии места вы фактически добавляете к нему.
В конечном счете, ответ на этот довольно загадочный вопрос - это сделать некоторые временные тесты. Если столбец B был намного больше, чем компонент A, я мог бы увидеть некоторые выигрыши. Для запросов, которые только использовать A, я мог бы увидеть некоторые выгоды. Тем не менее, я предполагаю, что такие достижения будут минимальными.
Когда вы говорите, что первый компонент ключа равен 4 байтам, это будет true, если 'A' были' VARCHAR (32) '? 'УАКСНАК (100)'? – ktm5124
@ ktm5124. , , И я пересмотрел ответ после того, как вы сделали это изменение. Размер 'varchar (32)' зависит от данных. Таким образом, он может быть как один байт, так и размером до + + макс. Длины. –
Вижу, спасибо. Вы упоминаете бенчмаркинг как один из способов узнать. Но когда дело доходит до MySQL, бенчмаркинг очень сложно из-за различного кэширования на всех уровнях (дисковый ввод-вывод, кэширование базы данных). Знаете ли вы о каких-либо беспроблемных способах проверки одного и того же запроса дважды? – ktm5124
Если вы выполнили запрос только на A, тогда индекс для A и B не будет использоваться, afaik. – sevenseacat
@sevenseacat вам лучше прочитать о самом левом правиле :) –
звучит так, как мне кажется. – sevenseacat