Комментарии 17
Это хорошая заметка от mysqlperformanceblog.com
Народ как всегда делится вроде бы мелочами, но какими!
Народ как всегда делится вроде бы мелочами, но какими!
Что-то я не понял: а индекс тут делается уже после того, как таблица заполнена?
А как быть при расстановке индексов при проектировании базы данных, когда невозможно провести такой анализ?
А как быть при расстановке индексов при проектировании базы данных, когда невозможно провести такой анализ?
Часто можно «прикинуть» селективность индекса ещё на этапе проектирования в зависимости от характера данных. Например, селективность по полю «возраст» будет очевидно выше чем селективность по полю «пол».
В остальных случаях лучше не торопиться.
В остальных случаях лучше не торопиться.
Все-таки при проектировании базы можно предварительно провести анализ. А практически, при проектировании сначала планируются те индексы, которые «must have», а потом уже добавляются по необходимости. А главное, это не забывать, что использование индексов не всегда идет во благо.
«Как видно, наиболее избирательным условием является «status=waiting»» — про понимание избирательности индекса автору оригинальной статьи ещё далеко.
Несколько странно слышать слово «эмпирический» — я не особый специалист по БД, но, например, в такой книжке High Performance MySQL про определение и использование индексов все подробно расписано.
Селективность индекса имеет значение (насколько я помню) имеет значение в случае когда индексируется только одно поле — причина в том, что в таком случае при низкой селективности индекса гораздо производительнее пробежаться во всем строкам, чем выгребать треть записей в хаотичном порядке по индексу.
В составном индексе, не может быть более одного поля входящего в диапазонный критерий — и такое поле должно быть последним.
Если вы ходите чтобы ORDER эффективно использовал индекс — тот же самый принцип.
Еще вы фиксированно задали значения критериев в запросе. Как будет работать такой запрос при source='yahoo', если там будет 2-3 записи?
В свете всего сказанного и учитывая что вам требуется всего одна запись — я бы попробовал сначала индекс (status, source, date) — это позволило бы избежать временной таблицы и filesort — а запись (одна) удовлетворяющая дополнительному критерию MySQL (no_send_before <= '2009-05-28 03:17:50' AND
tries <= 20) нашлась бы сканированием записей по индексу
Селективность индекса имеет значение (насколько я помню) имеет значение в случае когда индексируется только одно поле — причина в том, что в таком случае при низкой селективности индекса гораздо производительнее пробежаться во всем строкам, чем выгребать треть записей в хаотичном порядке по индексу.
В составном индексе, не может быть более одного поля входящего в диапазонный критерий — и такое поле должно быть последним.
Если вы ходите чтобы ORDER эффективно использовал индекс — тот же самый принцип.
Еще вы фиксированно задали значения критериев в запросе. Как будет работать такой запрос при source='yahoo', если там будет 2-3 записи?
В свете всего сказанного и учитывая что вам требуется всего одна запись — я бы попробовал сначала индекс (status, source, date) — это позволило бы избежать временной таблицы и filesort — а запись (одна) удовлетворяющая дополнительному критерию MySQL (no_send_before <= '2009-05-28 03:17:50' AND
tries <= 20) нашлась бы сканированием записей по индексу
Хочу поделиться простым эмпирическим методом...
Все-таки не стоит начинать перевод от первого лица. А то читаешь и думаешь, неужели mysqlperformanceblog.com начали переводить и выкладывать свои статьи на Хабр. По-моему, лучше делать вводное предложение. Допустим: Барон Шварц из mysq… предложил свой способ определения порядка столбцов в индексе. Сугубо личное мнение.
Да и так, не плохо вышло.
Я считаю, что при переводе вмешательство переводчика в оригинал должно быть минимальным (это не касается адаптации к русской аудитории, если она необходима). То, что предлагаете вы сделает топик просто топиком, имхо. Кстати из опыта знаю, что даже если статья написана не от первого лица — обязательно найдется возмущенный читатель, из уже видевших оригинал, который кинется намекать что я тут источников не указал и типа выдаю статью за свою. Думаю это проблема скорее интерфейса Хабра, то что топик — перевод, в глаза не бросается. Но все равно писать в топике-переводе что это топик-перевод и еще раз указывать ссылки мне кажется бредовой затеей
>> А то читаешь и думаешь
Вы и правда так подумали, если честно? :)
>> А то читаешь и думаешь
Вы и правда так подумали, если честно? :)
Если често, то я подумал, что кто-то перепечатал статью от своего имени.
Я не предлагал изменять перевод, я предложил только добавить введение в начало статьи, в котором бы описывалось, кто такой автор, о чем пишет и т.д. И, кстати, я закончил институт иностранных языков, где учат переводчиков.
Я не предлагал изменять перевод, я предложил только добавить введение в начало статьи, в котором бы описывалось, кто такой автор, о чем пишет и т.д. И, кстати, я закончил институт иностранных языков, где учат переводчиков.
Понимаете, когда я создаю топик-перевод — я в обязательном порядке указываю кто автор, ссылку на оригинал статьи, более того без этой информации топик-перевод и создать то нельзя. Вы предлагаете это делать дважды? Только для того, чтобы не самый, так скажем, внимательный читатель, не заметивший у заголовка иконку перевода и/или еще не заходя внутрь статьи или в ней самой не увидевший имя автора оригинала и ссылку, смог это прочитать непосредственно в тексте? Но ведь у тех, кто знает что такое топик-перевод никаких вопросов не возникает. Так же как и сомнений в присваивании чужих статей.
На Хабре как бы есть «формат» оформления таких топиков, я считаю правильным его придерживаться. И я не люблю дублирования информации в любом его виде. Делать же вступление, по моему это черезчур — ну тут заметка на несколько страниц все-таки, а не литературное произведение Драйзера.
На Хабре как бы есть «формат» оформления таких топиков, я считаю правильным его придерживаться. И я не люблю дублирования информации в любом его виде. Делать же вступление, по моему это черезчур — ну тут заметка на несколько страниц все-таки, а не литературное произведение Драйзера.
При таком методе, самое главное — где-то в начале не наткнуться на исключение из общей картины.
В данном примере, при первом подсчёте важно было взять именно source='twitter' а не source='the_fresh_twitter_clone' для которого sum(source='the_fresh_twitter_clone') дало бы 27, после чего все последующие расчеты были бы уже ложны.
Среднестатистический запрос ещё нужно уметь построить…
Думаю, что в таком методе, важно делать несколько разных запросов на каждом шагу.
В данном примере, при первом подсчёте важно было взять именно source='twitter' а не source='the_fresh_twitter_clone' для которого sum(source='the_fresh_twitter_clone') дало бы 27, после чего все последующие расчеты были бы уже ложны.
Среднестатистический запрос ещё нужно уметь построить…
Думаю, что в таком методе, важно делать несколько разных запросов на каждом шагу.
Мне кажеться, автор привел пример как увеличить скорость в уже существующих проектах.
а подскажите мне пожалуйста…
есть составной индекс из двух полей
при запросе
where field1=3
order by field2
все норм
при
where field1<3
order by field2
появляется filesort при изменении знака с '=' на '<' или '>'
есть составной индекс из двух полей
при запросе
where field1=3
order by field2
все норм
при
where field1<3
order by field2
появляется filesort при изменении знака с '=' на '<' или '>'
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Определяем порядок столбцов в составном индексе