Существует ли какой-нибудь смысл в альтерации InnoDB таблиц в которых хранятся товары, у которых есть группы, а сами товары разбросаны абы как, но 83% запросов приходятся именно на выборку товаров из какой-то заданной группы (тега)? Или наличие индекса по полю группы - это достаточное ускорение, чтобы отжать из таблицы все, на что она способна по скорости?

miksoftиспользовать покрывающие индексы.

javajdbcto the clustered index.


Это один и тот же зверь clustererd/покрывающий индекс?
И если да, то чем они отличаются от обычных индексов?

блин, пока разбирался, такая мешанина терминов!!
column index - синоним для index
clustered index - синоним для primary key, как бы самый главный дефолтный "secondary index", только на всю таблицу сразу
covering index - покрывающий индекс, то есть индекс, все поля которого есть в запросе
secondary index - копия таблицы для небольшого подмножества колонок, перечисленных в списке индекса, разновидность покрывающего индекса
multiple-column index - индекс с несколькими колонками (разновидность покрывающего индекса)
- composite index - синоним для multiple-column index
- combined index - синоним для multiple-column index
- compound index - синоним для multiple-column index

*

Короче, по моему вопросу из официальной доки из словарика вот такую фразу выдернул

авторIn the Oracle Database product, this type of table is known as an index-organized table.

И получается, что любая innoDB - это уже изначально сортированная таблица, поэтому вместо того, чтобы делать по ней alter ... order by достаточно просто правильно составить составной примарный ключ и он будет и покрывающим и таблицу внутри себя будет хранить в отсортированном виде

miksoftLumix clustered index - синоним для primary keyТолько для InnoDB, но не для MyISAM.

Правильно ли я понимаю, что создаваая на myisam ключ alter t add clustered key pageId мы тем самым как бы вручную превращаем myisam в innodb. То есть официально, "на бумаге" она остается myisam, а по факту фигачит как innodb. Верный ход мысли и понимания?


miksoftLumix covering index - покрывающий индекс, то есть индекс, все поля которого есть в запросеНаоборот, все поля запроса есть в индексе. Если в индексе будут "лишние" поля, то он не перестанет от этого быть покрывающим.

Правильно ли понимаю, что покрывающий - это когда ВООБЩЕ не происходит обращения таблице, а выборка идет исключительно через индекс?

Вопрос: это чисто бюрокаратическое/академическое замечание или индекс действительно перестает быть покрывающим?




Есть ли в данном смысле в целях использования покрывающего индекса все не входящие в индекс поля кидать в джоин?




miksoftLumix secondary index - копия таблицы для небольшого подмножества колонок, перечисленных в списке индекса, разновидность покрывающего индексаНе "разновидность". Покрывающие индексы обычно являются вторичными индексами, но далеко не всегда вторичные индексы являются покрывающими.

Ок, этот момент ясен.
Вопрос: Можно ли примарный ключ, кинутый на id, считать покрывающим для всех запросов типа таких? Правда ли, что в этом случае чтения таблицы не происходит, а результаты забираются только из индекса?





miksoftЧтобы индекс был "правильным" покрывающим (а "неправильные" и не нужны) нужно еще и чтобы его начальные поля способствовали ускорению запроса.

Прошу уточнить что имеется ввиду под этой туманной и загадочной формулировкой "способствовали ускорению".
Или может вы имеете ввиду банальные ситуации когда индексы бесполезны для like '%some' случаев?

MasterZiv, огромное спасибо за ответы!
У меня теперь очень качественно сейчас все устаканилось в голове по поводу индексов.

miksoftПока подбирал подходящую цитату в доке, нашел любопытный момент:
http://dev.mysql.com/doc/refman/5.6/en/index-extensions.html Before MySQL 5.6.9, the optimizer does not take into account the primary key columns of the extended secondary index when determining how and whether to use that index. As of 5.6.9, the optimizer takes the primary key columns into account, which can result in more efficient query execution plans and better performance.

Получается, что в наших базах данные которые пашут на 5.0.17 двигатель кладет болт на примарные индексы вообще что ли? То есть как бы получается, что нет смысла городить составной примарный индекс, а все равно придется делать отдельный вторичный составной индекс. В этом суть этого абзаца, да?

miksoftLumixпропущено...
Прошу уточнить что имеется ввиду под этой туманной и загадочной формулировкой "способствовали ускорению".
Или может вы имеете ввиду банальные ситуации когда индексы бесполезны для like '%some' случаев?Например, для запроса вида SELECT a,b FROM mytabel WHERE a=10 оба индекса (a,b) и (b,a) будут покрывающими. Но "правильным", т.е. дающим ускорение, будет только (a,b). Индекс (b,a) сможет быть использован только для его полного сканирования, но не для индексного доступа.

Ок, теперь вообще все по полочкам легло.

miksoftДа и то, если только явно заставить оптимизатор сделать это.

А чем мы можем форсить оптимизатор? Какие-то ключевые слова есть или модификаторы?

вадяmiksoftпропущено...
А причем тут эта статья?
Да и ссылок я там не вижу.
раздел - Похожие публикации
просто для информации для Lumix , он активно ищет инфу.

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

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

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

Если на мой конкретный вопрос дают совет прочитать какой-то учебник, то этот совет расширяет пространство и тем самым лишает меня возможности решить конкретный узкий вопрос из-за нехватки ресурсов. Например, для решения и глубокой проработки какого-то вопроса может потребоваться 3 часа, а для изучения материалов, на которые мне дают ссылку может потребоваться 20 дней и самое печальное, что в конечном итоге из этих 20 дней выяснится, что на мой изначальный вопрос материалу было всего-то 3 абзаца на странице 273-274 и вместо чтения учебника достаточно было бы прочитать всего эти три абзаца и это заняло бы 10 минут.

Вот пример по каким ссылкам я хожу
18285165
В этом сообщении я привел ссылку и снабдил её краткой выжимкой главной мысли.
Таким образом ссылка становится мгновенна понятна любому, а кто хочет деталей - может изучить статью.
Если бы эта ссылка была бы дана без этой краткой аннотации, тогда я никогда бы не перешел по ссылке.

Например, можно в качестве эксперимента задать ваде вопрос:
Вадя, вот вы дали ссылку на статью о миграции с MyISAM на InnoDB.
Текущая тема: хранения данных в таблицах в отсортированном виде.
приведите пожалуйста хоть одну цитату из этой статьи, которая по вашему мнению имеет отношение к обсуждаемой теме и позволяет более глубоко её понять

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

сообщите какая именно статья из раздела Похожие статьи имеет отношение к обсуждаемой теме

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

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

Если вы не сможете выполнить эти пункты, то ваша рекомендация прочитать эту статью - это точно такая же рекомендация как:
Lumix, прочитайте все статьи на хабре с ключевым словом InnoDB.

Я игнорирую подобные советы, потому что подобные советы может давать любой человек, не будучи даже близко экспертом.
Я изучаю внешние ссылки только когда вижу, что эксперт сам проработал этот материал, выжал из него главную мысль по обсуждаемой теме и четко указал какой именно кусок в приведенной ссылке относится к обсуждаемой теме. В этом случае, мне становится понятно, что перейдя по ссылке я более глубоко изучу вопрос и не потеряю время из-за расширения области поиска, спровоцированного "rtfm-троллем".