Как работает индексирование базы данных?
учитывая, что индексирование так важно, поскольку ваш набор данных увеличивается в размере, может ли кто-нибудь объяснить, как индексирование работает на агностическом уровне базы данных?
для получения информации о запросах для индексации поля, проверьте как индексировать столбец базы данных.
10 ответов
зачем это нужно?
когда данные хранятся на дисковых устройствах хранения, они хранятся в виде блоков данных. Доступ к этим блокам осуществляется полностью, что делает их операцией доступа к атомарному диску. Дисковые блоки структурированы так же, как и связанные списки; оба содержат Раздел для данных, указатель на местоположение следующего узла (или блока), и оба не должны храниться одновременно.
из-за того, что количество записей может только сортировка по одному полю, мы можем заявить, что поиск по полю, которое не сортируется, требует линейного поиска, который требует N/2 блокировать доступ (в среднем), где N - это количество блоков, которые охватывает таблица. Если это поле является неключевым (т. е. не содержит уникальных записей), то все табличное пространство необходимо искать в N заблокировать доступы.
в то время как с отсортированным полем может использоваться двоичный поиск, который имеет log2 N заблокировать доступы. Также с данные сортируются с учетом неключевого поля, остальная часть таблицы не нуждается в поиске повторяющихся значений, как только найдено более высокое значение. Таким образом, увеличение производительности является существенным.
что такое индексация?
индексирование-это способ сортировки нескольких записей по нескольким полям. Создание индекса на поле в таблице создает другую структуру данных, которая содержит значение поля и указатель на запись, к которой оно относится. Эта структура индекса затем сортируется, позволяя выполнять двоичный поиск на нем.
недостатком индексирования является то, что эти индексы требуют дополнительного места на диске, так как индексы хранятся вместе в таблице с помощью движка MyISAM, этот файл может быстро достичь пределов размера базовой файловой системы, если индексируется много полей в одной таблице.
как это работает?
во-первых, давайте набросаем пример схемы таблицы базы данных;
Field name Data type Size on disk id (Primary key) Unsigned INT 4 bytes firstName Char(50) 50 bytes lastName Char(50) 50 bytes emailAddress Char(100) 100 bytes
Примечание: char был использован вместо varchar, чтобы обеспечить точный размер на диске. Этот образец базы данных содержит пять миллионов строк и неиндексирован. Теперь будет проанализировано выполнение нескольких запросов. Это запрос с использованием id (отсортированное ключевое поле) и один, используя "имя" (неключевое поле несортированный).
Пример 1 - отсортированы против несортированных поля
учитывая наш образец базы данных r = 5,000,000 записи фиксированного размера, дающие длину записи R = 204 байты, и они хранятся в таблице с помощью движка MyISAM, который использует размер блока по умолчанию B = 1,024 байт. Блокирующий фактор таблицы будет bfr = (B/R) = 1024/204 = 5 записи на дисковый блок. Общее количество блоков, необходимых для хранения таблицы, составляет N = (r/bfr) = 5000000/5 = 1,000,000 блоки.
линейный поиск в поле id потребует в среднем N/2 = 500,000 блок обращается к поиску значения, учитывая, что поле id является ключевым полем. Но так как поле id также сортируется, двоичный поиск может быть проведен, требуя в среднем log2 1000000 = 19.93 = 20 заблокировать доступы. Сразу видно, что это радикальное улучшение.
теперь "имя" поле не сортируется и не является ключевым полем, поэтому двоичный поиск невозможен, а значения не уникальны, и поэтому таблица потребует поиска до конца для точного N = 1,000,000 заблокировать доступы. Это эту ситуацию индексация призвана исправить.
учитывая, что индексная запись содержит только индексированное поле и указатель на исходную запись, логично предположить, что она будет меньше многополевой записи, на которую она указывает. Таким образом, сам индекс требует меньше дисковых блоков, чем исходная таблица, что требует меньшего количества обращений к блокам для итерации. Схема для индекса на "имя" поле ниже;
Field name Data type Size on disk firstName Char(50) 50 bytes (record pointer) Special 4 bytes
Примечание: указатели в MySQL, 2, 3, 4 или 5 байт в зависимости от размера таблицы.
Пример 2 - индексации
учитывая наш образец базы данных r = 5,000,000 записи с длиной записи индекса R = 54 байты и использование размера блока по умолчанию B = 1,024 байт. Блокирующий фактор индекса будет bfr = (B/R) = 1024/54 = 18 записи на дисковый блок. Общее число блоки, необходимые для хранения индекса N = (r/bfr) = 5000000/18 = 277,778 блоки.
теперь поиск с помощью "имя" поле может использовать индекс для повышения производительности. Это позволяет осуществлять двоичный поиск индекса со средним значением log2 277778 = 18.08 = 19 заблокировать доступы. Чтобы найти адрес фактической записи, для которой требуется дальнейший блок доступа для чтения, приведите итог к 19 + 1 = 20 блок доступа, далеко от 1,000,000 блоков доступа, необходимых для поиска "имя" совпадение в неиндексированной таблице.
, когда его следует использовать?
учитывая, что создание индекса требует дополнительного дискового пространства (277 778 блоков дополнительно из приведенного выше примера, увеличение ~28%), и что слишком много индексов может вызвать проблемы, связанные с ограничениями размера файловых систем, необходимо тщательно продумать выбор правильных полей для индексирования.
, поскольку индексы используются только для ускорения поиска подходящего поля в записи, само собой разумеется, что индексирование полей, используемых только для вывода, будет просто пустой тратой дискового пространства и времени обработки при выполнении операции вставки или удаления, и поэтому следует избегать. Кроме того, учитывая характер двоичного поиска, важна мощность или уникальность данных. Индексирование на поле с мощностью 2 делило бы данные пополам, в то время как мощность 1000 возвращала бы приблизительно 1000 записей. При такой низкой мощности эффективность сокращается до линейной сортировки, и оптимизатор запросов избегает использования индекса, если мощность меньше 30% от номера записи, что делает индекс пустой тратой пространства.
В первый раз я прочитал это было очень полезно для меня. Спасибо.
С тех пор я получил представление о недостатке создания индексов:
если вы пишете в таблицу (UPDATE или INSERT) С одним индексом, то есть фактически две операции записи файловой системы. Один для табличных данных и другой для индексных данных (и его обращение (и - если они кластеризованы - обращение табличных данных)). Если таблица и индекс расположены на одном жестком диске, это стоит большее время. Таким образом , таблица без индекса (кучи) позволит быстрее выполнять операции записи. (если бы у вас было два индекса, у вас было бы три операции записи и т. д.)
однако определение двух разных местоположений на двух разных жестких дисках для индексных данных и табличных данных может уменьшить/устранить проблему увеличения стоимости времени. Это требует определения дополнительных групп файлов с соответствующими файлами на требуемых жестких дисках и определения местоположения таблицы / индекса как желанный.
еще одна проблема с индексами-их фрагментация во времени при вставке данных. REORGANIZE помогает, вы должны написать процедуры, чтобы это сделать.
в некоторых сценариях куча более полезна, чем таблица с индексами,
e.g: - Если у вас есть много конкурирующих пишет, но только один вечер читать в нерабочее время для отчетности.
кроме того, различие между кластеризованными и некластеризованными индексами весьма важно.
помог мне:- что на самом деле означает кластеризованный и некластеризованный индекс?
индекс - это просто структура данных, которая ускоряет поиск определенного столбца в базе данных. Эта структура обычно является b-деревом или хэш-таблицей, но это может быть любая другая логическая структура.
для получения дополнительной информации, я рекомендую: как работают индексы базы данных? И как индексы помогают?
классический пример индекс"в книгах"
рассмотрим "книгу" из 1000 страниц, разделенную на 100 разделов, каждый раздел с X страницами.
простой, да?
теперь, без индексной страницы, чтобы найти конкретный раздел, который начинается с буквы "S", у вас нет другого выбора, кроме сканирования всей книги. Я. e: 1000 страниц
но с индексной страницей в начале вы там. И больше, чтобы прочитать любой конкретный раздел, который важно, вам просто нужно просматривать страницу индекса, снова и снова, каждый раз. После нахождения соответствующего индекса вы можете эффективно перейти к разделу, пропустив другие разделы.
но тогда, в дополнение к 1000 страницам, вам понадобится еще ~10 страниц для отображения страницы индекса, так что полностью 1010 страниц.
таким образом, индекс представляет собой отдельный раздел, в котором хранятся значения индексированного столбца + указатель на индексированную строку в отсортированном порядке для эффективного вид окон.
в школах все просто, не так ли? : P
теперь предположим, что мы хотим запустить запрос, чтобы найти все детали любых сотрудников, которые называются "Abc"?
SELECT * FROM Employee
WHERE Employee_Name = 'Abc'
что бы произошло без индекса?
программное обеспечение базы данных буквально должно было бы смотреть на каждую строку в таблице Employee, чтобы увидеть, является ли Employeee_name для этой строки "Abc". И, поскольку мы хотим, чтобы каждая строка с именем " Abc "внутри нее, мы не можем просто перестать искать, как только мы найдем только одну строку с именем "Abc", потому что могут быть и другие строки с именем Abc. Таким образом, каждая строка до последней строки должна быть найдена – что означает, что тысячи строк в этом сценарии должны быть рассмотрены базой данных, чтобы найти строки с именем "Abc". Это то, что называется полное сканирование таблицы
как индекс базы данных может повысить производительность
весь смысл наличия индекса заключается в том, чтобы ускорить поисковые запросы, существенно сократив количество записи / строки в таблице, которые необходимо изучить. Индекс-это структура данных (чаще всего B - дерево), которая хранит значения для определенного столбца в таблице.
как работает индекс B-деревьев?
причина, по которой B - деревья являются наиболее популярной структурой данных для индексов, заключается в том, что они эффективны во времени – потому что поиск, удаление и вставки могут выполняться в логарифмическое время. И еще одна важная причина, по которой B-деревья чаще используются это потому, что данные, хранящиеся внутри B - дерева, могут быть отсортированы. СУБД обычно определяет, какая структура данных фактически используется для индекса. Но в некоторых сценариях с определенными СУБД можно фактически указать, какую структуру данных вы хотите использовать при создании самого индекса.
как работает индекс хэш-таблицы?
причина использования хэш-индексов заключается в том, что хэш-таблицы чрезвычайно эффективны, когда дело доходит до просто поиск ценностей. Таким образом, запросы, сравнивающие равенство со строкой, могут получать значения очень быстро, если они используют хэш-индекс.
например, запрос, который мы обсуждали ранее, может извлечь выгоду из хэш-индекса, созданного в столбце Employee_Name. Способ работы хэш-индекса заключается в том, что значение столбца будет ключом в хэш-таблице, а фактическое значение, сопоставленное с этим ключом, будет просто указателем на данные строки в таблице. Поскольку хэш-таблица в основном ассоциативный массив, типичная запись будет выглядеть примерно как "Abc => 0x28939", где 0x28939 является ссылкой на строку таблицы, где Abc хранится в памяти. Поиск значения типа " Abc "в индексе хэш-таблицы и возврат ссылки на строку в памяти, очевидно, намного быстрее, чем сканирование таблицы, чтобы найти все строки со значением" Abc " в столбце Employee_Name.
недостатки хэш-индекса
хэш-таблицы не сортируются по структурам данных, и там есть много типов запросов, с которыми хэш-индексы даже не могут помочь. Например, предположим, вы хотите узнать всех сотрудников, которым меньше 40 лет. Как вы могли сделать это с индексом хэш-таблицы? Ну, это невозможно, потому что хэш – таблица хороша только для поиска пар ключевых значений-что означает запросы, которые проверяют равенство
что именно находится внутри индекса базы данных? Итак, теперь вы знаете, что индекс базы данных создается в столбце таблицы, и что индекс хранит значения в этом конкретном столбце. Но, важно понимать, что индекс базы данных не хранит значений в других столбцах той же таблицы. Например, если мы создаем индекс в столбце Employee_Name, это означает, что значения столбцов Employee_Age и Employee_Address также не сохраняются в индексе. Если бы мы просто сохранили все остальные столбцы в индексе, это было бы так же, как создание другой копии всей таблицы, которая заняла бы слишком много места и будет очень неэффективно.
как база данных знает, когда использовать индекс? Когда выполняется запрос типа "SELECT * FROM Employee WHERE Employeee_name = 'Abc'", база данных проверяет, есть ли индекс в запрашиваемых столбцах. Предполагая, что столбец Employee_Name имеет индекс, созданный на нем, база данных должна будет решить, действительно ли имеет смысл использовать индекс для поиска значений – потому что есть некоторые сценарии, где на самом деле менее эффективно использовать индекс базы данных и более эффективно просто сканировать всю таблицу.
какова стоимость наличия индекса базы данных?
он занимает место – и чем больше ваша таблица, тем больше ваш индекс. Еще один удар по производительности с индексами заключается в том, что всякий раз, когда вы добавляете, удаляете или обновляете строки в соответствующей таблице, те же операции должны выполняться с вашим индексом. Помните, что индекс должен содержать те же самые до минуты данные, что и все, что находится в столбце(столбцах) таблицы, который охватывает индекс.
как правило, индекс должен создаваться только в таблице, если данные в индексированном столбце будут запрашиваться часто.
см. также
Простое Описание!!!!!!!!!!
индекс-это не что иное, как структура данных, которая хранит значения для определенного столбца в таблице. Индекс создается в столбце таблицы.
например, у нас есть таблица базы данных под названием User с тремя столбцами-Name, Age и Address. Предположим, что таблица User содержит тысячи строк.
теперь предположим, что мы хотим запустить запрос, чтобы найти все сведения о любых пользователях с именем "Джон". Если мы запустим следующий запрос.
SELECT * FROM User
WHERE Name = 'John'
программное обеспечение базы данных буквально должно было бы смотреть на каждую строку в пользовательской таблице, чтобы увидеть, является ли имя этой строки "Джон". Это займет много времени.
Именно здесь index помогает нам "index используется для ускорения поисковых запросов, существенно сокращая количество записей/строк в таблице, которая должна быть рассмотрена".
Как создать индекс
CREATE INDEX name_index
ON User (Name)
индекс состоит из значений столбцов (например: John) из одной таблицы, и что эти значения хранятся в структуре данных.
теперь база данных будет использовать индекс, чтобы найти сотрудников по имени Джон, потому что индекс предположительно будет отсортирован в алфавитном порядке по имени пользователей. И, поскольку он отсортирован, это означает, что поиск имени намного быстрее, потому что все имена, начинающиеся с "J", будут рядом друг с другом в индексе!
просто быстрое предложение.. Поскольку индексирование требует дополнительных операций записи и хранения, поэтому, если приложению требуется больше операций вставки/обновления, можно использовать таблицы без индексов, но если требуется больше операций извлечения данных, следует перейти к индексированной таблице.
просто подумайте об индексе базы данных как индексе книги. Если у вас есть книга о собаках, и вы хотите найти информацию, скажем, о немецких овчарках, вы можете, конечно, пролистать все страницы книги и найти то, что вы ищете, но это, конечно, занимает много времени и не очень быстро. Другой вариант заключается в том, что вы можете просто перейти в раздел индекса книги, а затем найти то, что вы ищете, используя имя объекта, который вы ищете ( в данном случае немецкий Пастухи), а также глядя на номер страницы, чтобы быстро найти то, что вы ищете. В базе данных номер страницы называется указателем, который направляет базу данных по адресу на диске, где находится объект. Используя ту же аналогию с немецкой овчаркой, мы могли бы иметь что-то вроде этого ("немецкая овчарка", 0x77129), где 0x77129-адрес на диске, где хранятся данные строки для немецкой овчарки.
короче говоря, индекс-это структура данных, которая хранит значения для определенного столбца в таблице, чтобы ускорить поиск запросов.
SQL index-это что-то, связанное с ускорением поиска в базе данных SQL. Индекс позволяет программисту извлекать данные из базы данных очень быстро. Предположим, вы студент или читатель. Ваша книга содержит 50 000 страниц. В первый день Вы читаете какую-то тему "ABC" на следующий день вы хотите прочитать еще одну тему "xyz". вы никогда не будете вручную просматривать страницу за страницей. Что вы будете делать в этой ситуации, это использовать индекс книги, чтобы посмотреть определенную тему, а затем перейти непосредственно к теме. Индекс сэкономил много времени на поиск темы. То же самое в SQL index, Index позволяет очень быстро искать миллионы записей из базы данных.
индекс базы данных-это структура данных, которая повышает скорость операций поиска данных в таблице базы данных за счет дополнительных записей и пространства хранения для поддержания структуры данных индекса. Индексы используются для быстрого поиска данных без необходимости поиска каждой строки в таблице базы данных при каждом доступе к таблице базы данных. Индексы могут быть созданы с использованием одного или нескольких столбцов таблицы базы данных, обеспечивая основу как для быстрого случайного поиска, так и для эффективного доступа упорядоченных учетная документация.