Когда является индекс (в DBMS) плохим индексом?
Я использовал свойство mongooose Populate, чтобы проверить мой код. Это поможет вам понять.
Схема категории
const mongoose = require('mongoose');
const timestamps = require('mongoose-timestamp');
const cateorySchema = new mongoose.Schema({
category_name: {
type: String,
trim: true,
required: true,
},
active: {
type: Boolean,
default: true,
}
});
cateorySchema.plugin(timestamps); // automatically adds createdAt and updatedAt timestamps
module.exports = mongoose.model('Category',cateorySchema);
Схема подкатегории
'use strict'
const mongoose = require('mongoose');
const timestamps = require('mongoose-timestamp');
const subCategorySchema = new mongoose.Schema({
categories:{ type: mongoose.Schema.Types.ObjectId, ref: 'Category' },
subcategorytitle:{
type:String,
trim:true,
required: true
},
active: {
type: Boolean,
default: true
}
});
subCategorySchema.plugin(timestamps); // automatically adds createdAt and updatedAt timestamps
module.exports = mongoose.model('Subcategory',subCategorySchema);
Надеюсь, это поможет вам. Если у вас есть какие-либо сомнения, дайте мне знать.
8 ответов
Я уже связывался с ним раньше, и я свяжусь с ним снова, потому что он превосходный:
Одно обстоятельство, при котором индекс в значительной степени безусловно плох, - это наличие другого индекса, который использует те же столбцы (в том же порядке ) в качестве префикса:
CREATE INDEX ix_good ON SomeTable(Col1, Col2, Col3);
CREATE INDEX ix_bad ON SomeTable(Col1, Col2);
Плохой индекс - это бесполезная трата дискового пространства и бесполезное замедление операций изменения.
Индекс плох, если вы никогда не выполняете поиск по нему. Например, индекс (Col1, Col2, Col3) является пустой тратой ресурсов, если вы никогда не выполняете поиск с помощью Col1, Col2 и Col3 в одном запросе.
Наличие индексов (создание и обслуживание структуры) снижает производительность. Обычно вы хотите, чтобы это попадание использовалось для более быстрого сканирования. Когда вы не получаете выгоды, это просто чистый убыток, а это плохой индекс.
Возможные причины:
- Никогда не использовались индексы
- Избыточные индексы
- Таблицы, которые не сканируются очень часто, но постоянно обновляются (наличие индекса перевешивает преимущества, потому что таблица редко просматривается).
- Таблицы, которые часто сканируются и постоянно обновляются. В этом случае вы можете получить как преимущество индекса, так и мгновенное обновление / вставку, имея таблицу без индекса для вставок / обновлений и таблицу с индексами для сканирований, которая обновляется ежедневно или ежечасно (есть случаи, когда это не так. не работает, конечно. Затем вам нужно получить лучшее оборудование или переделать приложение, если в таком случае у вас возникнут серьезные проблемы с производительностью).
Как найти плохие индексы? В большинстве СУБД есть опции для отображения плана запроса, где вы можете увидеть, используются ли настроенные вами индексы так, как вы ожидаете. Это подводит меня к последнему совету: подумайте о своих индексах, никогда не создавайте их «на всякий случай».
Если поиск в индексированном столбце не ведется, а таблица сильно обновляется, вы не получите преимущества производительности, для которой предназначены индексы. Напротив, производительность может снизиться.
Одна важная вещь, о которой следует помнить при работе с индексами (помимо вышеупомянутой части «фактическое использование»), - это понятие избирательности.
При построении индексов вы хотите создавать индексы для столбцов, которые имеют хорошие шансы на «высокую избирательность». Это требует некоторого понимания данных в столбце (которые вы можете иметь или не иметь в зависимости от вашего знания домена / наличия выборочных данных).
Селективность = количество отличных значений / общее количество строк
Допустим используйте таблицу «Люди» со столбцами для Given_name, Surname, Gender, Age
. Например, создание индекса для столбца, такого как Gender (где пол ограничен NULL, M или F), не принесет большой пользы во время запрос (особенно если запрос уже приводит к сканированию таблицы по другим причинам). При любом раскладе селективность этого индекса была бы крайне низкой. В зависимости от СУБД использование этого индекса может оказаться хуже, чем полное сканирование таблицы.
Однако создание составного индекса для (Given_name, Surname) даст преимущества при выполнении запросов к этим столбцам. Избирательность этого индекса (для большинства популяций) была бы довольно хорошей.
Индекс с селективностью 1 является идеальным, однако единственный способ достичь селективности 1 - иметь уникальный индекс для столбца, не допускающего значения NULL.
Также имейте в виду, что вы можете легко писать запросы, чтобы «отслеживать» ваши индексы и их избирательность.
Surname) даст преимущества при выполнении запросов к этим столбцам. Избирательность этого индекса (для большинства популяций) была бы довольно хорошей.Индекс с селективностью 1 является идеальным, однако единственный способ достичь селективности 1 - иметь уникальный индекс для столбца, не допускающего значения NULL.
Также имейте в виду, что вы можете легко писать запросы, чтобы «отслеживать» ваши индексы и их избирательность.
Surname) даст преимущества при выполнении запросов к этим столбцам. Избирательность этого индекса (для большинства популяций) была бы довольно хорошей.Индекс с селективностью 1 является идеальным, однако единственный способ достичь селективности 1 - иметь уникальный индекс для столбца, не допускающего значения NULL.
Также имейте в виду, что вы можете легко писать запросы, чтобы «отслеживать» ваши индексы и их избирательность.
Если поле никогда не используется, это плохой индекс (если вы чувствуете, что ненужные вещи - это плохо).
Индекс помогает нам быстрее искать строки.
Если столбец индекса не используется для поиска , нет смысла его определять.
] Если значения в этом столбце продолжают изменяться очень часто, это будет дополнительной работой для сервера базы данных (для повторной индексации)
Если имеется слишком много вставок и удалений из таблицы это будет дополнительная работа для сервера