Есть ли разница в скорости работы MySQL? - PullRequest
1 голос
/ 19 февраля 2009

Я обсуждал скорость операторов MySQL, и кто-то спросил меня: между SELECT, INSERT, UPDATE и DELETE, что быстрее и почему?

Я не знал ответа. Кто-нибудь знает, быстрее ли один, чем другой, и если да, то почему? Или у них вообще одинаковая скорость?

Ответы [ 5 ]

1 голос
/ 19 февраля 2009

В основном "это зависит".

Например, если база данных обслуживает много одновременных пользователей, то количество времени, в течение которого таблица заблокирована, будет иметь большее значение, чем общее время выполнения запроса.

Как правило, я бы сказал:

INSERT обычно выполняется быстрее, так как он только добавляет данные и не нуждается в блокировке таблицы, потому что никакие существующие данные не изменяются. Хотя множество индексов может немного замедлить его.

ВЫБОР потенциально может быть очень быстрым или очень медленным. Это зависит от запроса. Он может быть самым быстрым и не блокирует стол. Но операции SELECT часто намного сложнее, чем другие, выбирая данные из нескольких таблиц или сортируя или используя индексы более полно.

УДАЛИТЬ относительно медленно. Таблица (или, в зависимости от механизма хранения, затронутых строк) должна быть заблокирована. Индексы нуждаются в обновлении.

ОБНОВЛЕНИЕ обычно самое медленное. Таблицу (или в зависимости от механизма хранения, затронутые строки) необходимо заблокировать, индексы нужно обновить, и это несколько сложнее, чем УДАЛИТЬ.

Но, как я уже сказал, это все практическое правило, и оно действительно во многом зависит от обстоятельств.

0 голосов
/ 19 февраля 2009

Скорость запросов к базе данных действительно может быть измерена только как относительно каждого другого. Для большинства простых запросов это номинальная разница в миллисекундах.

Лучшую проблему следует рассматривать с точки зрения «сколько вещей вы производите?».

  • Запрос может принимать различные формы, но если вы выбираете из 3 таблиц, он, вероятно, будет медленнее, чем 2 таблицы.
  • Использование LIMIT поможет выполнить запрос быстрее во всех случаях
  • Индексы могут помочь запросу, если он использует их правильно
  • Обновление индексов занимает время
  • Для работы с большими таблицами требуется больше времени

Список можно продолжить, но обычно я строил и работал над медленными точками после свершившегося факта. Большинство людей на самом деле не так сильно загружают свои базы данных:)

0 голосов
/ 19 февраля 2009

При условии простых запросов и общих сценариев и конфигураций использования, SELECT будут самыми быстрыми, потому что они оба наиболее легко кэшируются (всем: ЦП, диском, ОС, памятью MySQL и кешем запросов MySQL) и наиболее часто выполняются ( разрешить использование указанных кэшей).

Все остальные операции являются операциями записи, которые занимают гораздо больше времени и не могут быть кэшированы. Время работы даже простых запросов на запись часто сильно зависит от того, насколько загружена загрузка (запросы SELECT) на сервере.

0 голосов
/ 19 февраля 2009

Вы не совсем задаете правильный вопрос. Например, SELECT должен каким-то образом вычислить набор всех строк, соответствующих выбору, а затем вернуть их через некоторый механизм, который может быть чем угодно, из динамического массива с большой задницей в чем-то вроде sqlite (потому что он в памяти и в том же процессе) к данным, передаваемым удаленно через Интернет.

Так, например, SELECT * FROM USERDATA возврат 10 строк локально может занять микросекунды, но займет несколько минут, если он возвращает 10 000 000 строк через глобальную сеть.

0 голосов
/ 19 февраля 2009

Я не уверен в каждой команде в отдельности, но многое зависит от фактического утверждения. Наличие индексов в таблице требует, чтобы индексы модифицировались при вставках, обновлениях и удалениях. Хотя индекс может сделать выбор быстрее, он замедляет любые операторы изменения данных. Кроме того, сложность запроса, тип данных столбцов, любые функции sql (например, агрегаты) влияют на производительность запроса.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...