Статья: Оптимизация запросов в MySQL

[Falc]

Статья: Оптимизация запросов в MySQL

Написал я статейку:
http://detail.phpclub.net/temporary.phtml

Прошу критиковать.

Приветствуются любые комментарии и замечания. Постараюсь учесть все пожелания.

 

[Апельсин]

> COUNT(*) vs COUNT(field)

вообще-то данные выражения возвращают разные результаты, и сравнение приведенное тобой в статье некорректно.

 

[Falc]

Апельсин
Согласен.

Если будет COUNT(*) vs COUNT(id) подойдет или нужно пояснение?

 

[Alexandre]

нужно пояснение

 

[Falc]

Alexandre
ок

 

[Sad Spirit]

Re: Статья: Оптимизация запросов в MySQL

Автор оригинала: Falc
Прошу критиковать.

С нашим удовольствием:

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

Все татары кроме я?

SELECT * FROM table WHERE field1 = 123, field2 = 234

Я отстал от жизни или запрос действительно вывалит синтаксическую ошибку?

Скорость вставок и обновлений в базе в основном зависит от количества и индексов в таблице и размера таблицы, чем больше индексов и размер таблицы, тем медленнее будут происходить данные операции

Опять "все татары кроме я"...

Я, конечно, согласен, что программисты MySQL люди до крайности криворукие, но думаю, что операция вставки всё же даже у них получилась O(1), а не O(N).

 

[Falc]

Sad Spirit

Спасибо за коментарии, постараюсь исправить найденные тобой ошибки.

>>Я, конечно, согласен, что программисты MySQL люди до крайности криворукие, но думаю, что операция вставки всё же даже у них получилась O(1), а не O(N).

Поясни свою мысль, я не совсем понял о чем ты.

Если ты про то, что скорость вставки не зависит от размера таблицы, то это не совсем так, так как в мануале написано:
"Размер таблицы замедляет вставку индексов в log N раз (B-деревья)."
Так что зависимость есть, хотя и далеко не линейная.

 

[Sad Spirit]

Автор оригинала: Falc
Если ты про то, что скорость вставки не зависит от размера таблицы, то это не совсем так, так как в мануале написано:
"Размер таблицы замедляет вставку индексов в log N раз (B-деревья)."
Так что зависимость есть, хотя и далеко не линейная.

Сорри, недостаточно точно выразился. Я имею в виду, что время вставки записи в таблицу от размера таблицы не зависит. С индексами-то всё понятно.

 

[Falc]

Статью обновил.

http://detail.phpclub.net/temporary.phtml

По новой версии будут еще замечания?

 

[young]

ну так что, публикуем?

 

[Falc]

young
Давай подождем до конца недели, если коментов не будет я в понедельник пришлю тебе немного обновленый вариант и ты его опубликуешь.

 

[Sad Spirit]

Кстати о птичках, а про мою-то статью окончательно забыли?

 

[young]

http://detail.phpclub.net/article/mysql_optimize
Status: published

Кстати о птичках, а про мою-то статью окончательно забыли?

Status: published (html, pdf)
2Sad Spirit: допиши копирайты

 

[Найч]

Немного по нашему могучему...

Для того чтобы посмотреть как будет выполнятся запрос на выборку используется оператор EXPLAIN:

Вроде мягкий знак нужен.

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

Упущена запятая.

Основная ошибка начинающих это отсутствие индексов

Тире

Однако это утверждение верно только в том случае если выборка будет происходить

Запятая

Если к примеру оптимизатор MySQL

"к примеру" в запятые взять

порядке: c,b,a то

запятая перед "то"

Иногда бывает такая ситуация что нам постоянно

Запятая

таблицы, например во многих

"например" в запятых. Кстати, по всей статье поставьте это слово в запятые.

Также если мы несколько раз рассчитываем агрегатную функцию для одних и тех же данных. То для ускорения следует сделать такой расчет отдельно и положить его результат во временную таблицу.

Полагаю, здесь запятая.

Для увеличения быстродействия такой выборки необходимо вынести подсчет MAX’а или COUNT’а вынести в отдельный запрос.

"вынести" два раза

Почему COUNT(*), обычно быстрее COUNT(id)

А здесь запятая не нужна

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

Я ба написАл так:
Для выполнения первого запроса нам достаточно просто пробежаться по индексу user_id и подсчитать кол-во записей, удовлетворяющих условию - такая операция достаточно быстрая, т.к. ,во-первых, индексы у нас упорядочены и, во-вторых, часто находятся в буфере.

Для выполнения второго запроса мы сначала проходим по индексу, для отбора записей удовлетворяющих условию

Запятая лишняя

В итоге получаем что при большом

перед "что" запятая

только те индексы в которых присутствуют

Запятая

Условия в запросах на обновления оптимизируются также как и в случае с выборками.

Лучше так:
Условия в запросах на обновления оптимизируются так же, как и в случае с выборками.

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

Запятая лишняя

Извиняюсь, если где ошибся.

 

[Falc]

Найч
Спасибо, с русским у меня всегда были проблемы.

-~{}~ 23.03.04 12:10:

Найч
Вроде все исправил, статья обновлена.

 

[Sad Spirit]

Автор оригинала: young
Status: published (html, pdf)
2Sad Spirit: допиши копирайты

С удовольствием, как только снова заставлю нормально работать pdflatex.
Пока он выдаёт результаты, которые публиковать не стоит.

 

[Найч]

Falc
Взгляд со стороны.
Неплохо было бы, если бы ты описАл на пальцах (с примерами) работу+ньюансы explain. Кроме того, что в мане. Для продвинутых пользователей мускула, которым необходимо вылизать свои запросы. А то как-то сухонько все написано...

 

[Falc]

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

Бывают к примеру такие случаи когда выборки по индексам работат медленее чем не по индексам. Иногда разбиение одного запроса на 2 дает очень хороший эфект такого тоже через explain не отследишь.

А для того чтобы заставить работать свои запросы по индексам достаточно описания в мане.

Еще раз повторю моей задачей было не пересказать ман а описать те вещи о которых в нем не сказано или сказано очень мало.

Да кстати в верху даного топика устаревший вариант статьи, вот новый:
http://detail.phpclub.net/article/mysql_optimize

 

[Найч]

explain очень продробно описан в мане лучше чем там я его не опишу

Жаль. В мане нет "опыта". И мало примеров, хотя по ним эффективнее всего учиться.

 

[Falc]

Найч
>>Жаль. В мане нет "опыта". И мало примеров, хотя по ним эффективнее всего учиться.

Насчет примеров это верно подмечено, я подумаю над этим.