Индексы хороши или плохи для большой базы данных?
Я читал на MySQL Performance Blog, что, когда таблицы являются большими, лучше просканировать полные таблицы, вместо того, чтобы использовать индексы.
У меня есть таблица с десятками миллионов строк. Когда проведение запросов, если я не использую индексов, затем запрашивает, в 24 раза медленнее, чем с индексами. Я знаю, что партия вещей может вызвать это (например, строки хранятся последовательно), но можно дать мне некоторые подсказки, что могло бы происходить? Или как я должен начать исследовать эту проблему? Я хочу понять, когда использование индексов предпочтено и когда это не
Спасибо
3 ответа
В статье говорится, что при работе с очень большими наборами данных, когда количество строк, с которыми вам нужно работать, приближается к количеству строк в table, использование индекса может снизить производительность.
В этом случае просмотр индекса действительно снизит производительность, если вам нужно больше данных, чем представлено в индексе.
Чтобы пройти через индекс, движок базы данных сначала должен прочитать большие части индексной таблицы (это тип таблицы), а затем для каждой строки (или набора строк) из этого результата перейти к реальной таблице. и начните выбирать страницы для чтения.
Если, с другой стороны, вам нужно получить только столбцы, которые уже являются частью индексной таблицы, то движок базы данных должен только читать из нее, а не переходить к полной таблице за дополнительными данными.
Если вы в конечном итоге прочитаете большую часть или почти всю фактическую рассматриваемую таблицу, вся работа, необходимая для работы с индексом, может быть больше накладных расходов, чем просто выполнение полного сканирования таблицы для начала.
Это все , о которых говорится в статье. Для большей части работы с базой данных использование индексов является правильным решением.
Например, если вам нужно извлечь небольшой набор строк, просмотр индекса вместо полного сканирования таблицы будет на много порядков быстрее.
В любом случае, если вы сомневаетесь, вам следует провести профилирование производительности, чтобы узнать, как ваше приложение ведет себя при различных типах нагрузок, а затем начать настройку. Не воспринимайте ни одну статью как серебряную пулю для что-нибудь.
Например, одним из способов ускорить выполнение примеров запросов, которые производят подсчет в столбце pad в статье, было бы создание единого индекса, охватывающего как val , так и pad , таким образом, счет будет просто сканированием индекса, а не сканированием индекса + поиском по таблице, и будет выполняться быстрее, чем полное сканирование таблицы.
Ваш лучший вариант - это знать свои данные, экспериментировать и знать, как работают инструменты, которые вы используете, так что действительно, узнайте больше об индексах, но, в конце концов, вы решаете что лучше для вашей программы.
Как всегда, это зависит от обстоятельств. Я до сих пор ни разу не встречал сценария, описанного в тех сообщениях в блоге. Использование индексов в моих запросах для больших (более 50 миллионов строк) было от 100 до 10000 раз быстрее, чем полное сканирование этих больших таблиц.
Здесь, вероятно, нет серебряной пули, вы должны проверить свои конкретные данные и свои конкретные запросы.
Рекомендуется помещать индекс в каждый столбец, который вы использовали в предложении WHERE .