Новая статья "Оптимизация запросов в MySQL"

  • Автор темы Автор темы Falc
  • Дата начала Дата начала
"Иногда бывает такая ситуация что нам постоянно приходится делать выборки из одной и той же части некоторой очень большой таблицы" тут надо добавить "редко изменяющейся"
 
Суханькая статья.
Раз уж упомянули про explain может объяснить как им пользоваться на примерах.
 
если в таблице делаются инсерты и апдейты то временная таблица уже содержит неверную информацию
 
HEm
>>если в таблице делаются инсерты и апдейты то временная таблица уже содержит неверную информацию

От этого только плюс.

-~{}~ 23.03.04 11:38:

nRay
>>Суханькая статья.
>>Раз уж упомянули про explain может объяснить как им пользоваться на примерах.

Старался не расказать только про то чего нету в мануале, про эксплаин в мануале очень подробно написано, зачем дублировать?
 
ForJest
Я бы назвал этот круг "Продвинутый новичок", т.е. те кто ман уже прочитал, но тонкостями разработки еще не овладел.
 
:)))
Значитс... что было придумано мною - каждой статье будет привоен уровень читателя - новичок, разработчик или эксперт

и будет возможность фильтровать статьи по уровню подготовки читателя, а так же видеть в общем списке, кому она предназначена.
 
young
неплохая мысль
p.s. а термины можно обсудить, а то найдутся недовольные, открой тему
 
HEm
Ты решил больше не отстаивать свою точку зрения по поводу добавления "редко изменяющейся"?
 
Falc
"От этого только плюс." - тут я просто растерялся, в чем он?
 
HEm
Немного поясню.

Временая таблица существует только в пределах одного соединения. Т.е. если вы используете обычное соединение с базой. то только во время работы скрипта.
В итоге если выборка идет не из временой таблицы может оказаться, что в начеле скрипта виведутся одни данные, а в середине и в конце другие, это кстати может привести даже к критичной ошибке. При выборке же из временой таблицы такой ошибки не возникнет.
 
Автор оригинала: young
:)))
Значитс... что было придумано мною - каждой статье будет привоен уровень читателя - новичок, разработчик или эксперт

и будет возможность фильтровать статьи по уровню подготовки читателя, а так же видеть в общем списке, кому она предназначена.
Предлагаю дать возможность ЧИТАТЕЛЮ выбирать уровень статьи. Т.е. типа голосования.
 
Предлагаю дать возможность ЧИТАТЕЛЮ выбирать уровень статьи. Т.е. типа голосования.
голосвание уже есть. правда, в виде оценки статьи. слева.

а возможности влиять на уровень статьи у читателя не будет. обнозначно.
 
Falc, действительно сухо местами. Просто формулировки. Не хватает "воды", живости, примеров в некоторых частях.
Где было замечено:
Также если мы несколько раз рассчитываем агрегатную функцию для одних и тех же данных, то для ускорения следует сделать такой расчет отдельно и положить его результат во временную таблицу.
Просто зависшее в воздухе утверждение. Ты ни в чём читателя не убеждаешь им. Просто утверждение.
"Кто умный - тот сам поймёт" для этого случая не подходит, так как если это продвинутый новичок, то ему нужно дать информацию к размышлению - пример, реализацию одну и другую их сравнения и преимущества подхода. Обучающие статьи так обычно и пишутся

"Скорость вставок и обновлений в базе зависит от размера вставляемой (обновляемой) записи и от времени вставки индексов. Время вставки индексов в свою очередь зависит от количества вставляемых индексов и размера таблицы. Эту зависимость можно выразить формулой:
[Время вставки индексов] = [кол-во индексов] * LOG2( [Размер таблицы] )
При операциях обновления под [кол-во индексов] понимаются только те индексы, в которых присутствуют обновляемые поля.
Условия в запросах на обновления оптимизируются так же, как и в случае с выборками.
В данном случае не хватает просто воды - выдаются сведения, которые ничем не закрепляются.
[Время вставки индексов] = [кол-во индексов] * LOG2( [Размер таблицы] - в каких единицах измеряется время?
Вода, которую необходимо вставить - "К примеру если у вас есть таблица (описание таблицы) с индексами на поля (указываем индексы) и в этой таблице 2000000 записей - то вставка будет происходить (расчёт) секунд (или миллисекунд)"

"Условия в запросах на обновления оптимизируются так же, как и в случае с выборками." Эту часть я думаю лучше поместить после "С его помощью мы можем посмотреть, в каком порядке будут связываться таблицы и какие индексы при этом будут использоваться." Что-то типа "Следует отметить что все части WHERE вне зависимости от того является ли этот запрос SELECT, UPDATE или DELETE оптимизируются одинаково, поэтому данному разделу советую уделить пристальное внимание."
 
Сверху