Запрос 1 просматривает индекс первичного ключа таблицы, находит правильные 600 000 идентификаторов и соответствующие им местоположения в таблице, затем переходит к таблице и извлекает все из этих 600 000 местоположений.
Запрос 2 просматривает индекс первичного ключа таблицы, находит правильные 600 000 идентификаторов и их соответствующие местоположения в таблице, затем переходит к таблице и извлекает подмножество полей, запрашиваемых из этих 600 000 строк.
Запрос 3 просматривает индекс первичного ключа таблицы, находит правильные идентификаторы 600k и возвращает их. Совершенно не обязательно смотреть на стол.
Запрос 4 просматривает индекс первичного ключа таблицы, находит запрошенную единственную запись, обращается к таблице, считывает эту единственную запись и возвращает ее.
По времени давайте построим в обратном порядке:
(Q4) Индекс таблицы позволяет искать ключ (id) за время O(log n), то есть каждый раз, когда размер таблицы удваивается, требуется всего один дополнительный шаг, чтобы найти ключ в индексе*. Если у вас есть 1 миллион строк, то для его поиска потребуется всего около 20 шагов. Миллиард строк? 30 шагов. Запись индекса включает данные о том, где в таблице нужно найти данные для этой строки, поэтому MySQL переходит к этому месту в таблице и читает строку. Время, указанное для этого, почти полностью накладное.
(Q3) Как я уже упоминал, индекс таблицы работает очень быстро; этот запрос находит первую запись и просто проходит по дереву, пока не наберет запрошенное количество строк. Я уверен, что смогу рассчитать точное количество шагов, которое потребуется, но как максимум мы скажем, что 20 шагов x 600 тысяч строк = 12 миллионов шагов; поскольку он пересекает дерево, это, вероятно, будет больше похоже на 1 миллион шагов, но точное число в значительной степени не имеет значения. Самое важное, что нужно понять, это то, что после того, как MySQL пройдется по индексу, чтобы получить нужные ему идентификаторы, у него будет все, что вы просили. Нет необходимости идти смотреть на стол. Время, указанное для этого, по сути, является временем, которое требуется MySQL для обхода индекса.
(Q2) Это начинается с того же обхода дерева, который обсуждался для запроса 3, но при извлечении необходимых ему идентификаторов MySQL также извлекает их местоположение в файлах таблиц. Затем он должен перейти к файлу таблицы (возможно, уже кэшированному/mmapped в памяти) и для каждой извлеченной записи искать нужное место в таблице и получать запрошенные поля из этих строк. Время, сообщаемое для этого запроса, — это время, необходимое для обхода индекса (как в вопросе 3), плюс время для посещения каждой строки, указанной в индексе.
(Q1) Это идентично Q2, когда указаны все поля. Поскольку время, по сути, идентично Q2, мы можем видеть, что на самом деле не требуется значительно больше времени, чтобы извлечь больше полей из базы данных, каждый раз, когда они затмеваются сканированием индекса и поиском строк.
*: В большинстве баз данных используется индексирующая структура данных (B-деревья для MySQL), которая имеет база журнала намного выше 2, а это означает, что вместо дополнительного шага каждый раз, когда таблица удваивается, это больше похоже на дополнительный шаг каждый раз, когда размер таблицы увеличивается в сотни или тысячи раз. Это означает, что вместо 20-30 шагов, которые я указал в примере, это скорее 2-5.
person
Kevin
schedule
27.06.2013
