MySQL InnoDB => композиционный ПК и вторичный индекс

Я понимаю, что ПК является частью каждого вторичного индекса в InnoDB, но то, что об этой ситуации:MySQL InnoDB => композиционный ПК и вторичный индекс

У меня есть таблица структуры с двумя колонками

а, б

Я выбираю PK как + б

и создать INDEX на б

Вопрос в том, как выглядит структура вторичного индекса?

ли она хранится как

б в

или

б а + б

Или другой, более подробный пример:

стол: улица, город, штат, почтовый индекс, fk_customers

PK: fk_customers + улица + город + почтовый

INDEX (город)
INDEX (улица)

Are вторичные индексы, хранящиеся следующим образом:

город fk_customers + улица + почтовый
улица fk_customers + город + почтовый

или как это:

город fk_customers + улица + город + почтовый
Улица fk_customers + улица + город + почтовый индекс

источник

2014-11-21 Dusan Cani

несвязанные: 'fk_customers' это страшное название для столбца , Понятие FK логично и не относится к определению необработанных данных. Что делать, если FK находится на 2 столбцах? Вы бы назвали их 'fk_customers1' и' fk_customers2'? Имена столбцов должны отражать функциональные данные, которые они должны быть. то есть 'customer_id' или что бы вы ни предпочли. – Sebas

«Что делать, если FK находится на 2 столбцах?» - Я использую одиночные (не многоколонные) отношения таблицы PK-FK, поэтому я не вижу никаких проблем с ним. Этот формат хорошо читается для меня, я могу быстро идентифицировать FK-появление, когда я смотрю на определение таблицы. –

Вы пропустили точку. – Sebas

Это легко проверить.Мое шестое чувство, сказало вторичный ключ на b будет b a b, но InnoDB достаточно умен, чтобы опустить излишний b:

mysql> create table t1 (a varchar(32), b varchar(32), primary key (a,b)); 
mysql> alter table add index(b); 
mysql> insert into t1 values('aaa','bbb'); 
Query OK, 1 row affected (0.00 sec)

Вот шестнадцатеричный вторичного индекс страницы:

00004000 07 11 7d 29 00 00 00 04 ff ff ff ff ff ff ff ff |..})............| 
00004010 00 00 00 00 ff ee cf d5 45 bf 00 00 00 00 00 00 |........E.......| 
00004020 00 00 00 00 09 31 00 02 00 85 80 03 00 00 00 00 |.....1..........| 
00004030 00 7f 00 05 00 00 00 01 00 00 00 00 00 01 e0 7e |...............~| 
00004040 00 00 00 00 00 00 00 00 18 1a 00 00 09 31 00 00 |.............1..| 
00004050 00 02 02 72 00 00 09 31 00 00 00 02 01 b2 01 00 |...r...1........| 
00004060 02 00 1c 69 6e 66 69 6d 75 6d 00 02 00 0b 00 00 |...infimum......| 
00004070 73 75 70 72 65 6d 75 6d 03 03 00 00 10 ff f1 62 |supremum.......b| 
00004080 62 62 61 61 61 00 00 00 00 00 00 00 00 00 00 00 |bbaaa...........| 
00004090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Как вы видите, , столбец a идет сразу после ключевого столбца b. Там нет заднего b

источник

2014-11-21 18:40:43 akuzminsky

Ответа выше, akuzminsky является правильным, но добавить немного больше обсуждения: На самом деле это обсуждается в моем блоге «The physical structure of records in InnoDB» под заголовком «Вторичных индексов»:

Например, если таблица имеет ПЕРВИЧНЫЙ КЛЮЧ (a, b, c) и вторичный индекс KEY (a, d), вторичный ключ в индексе будет таким, как ожидалось, (a, d), но PKV будут содержать только (До нашей эры).

Вы также можете подтвердить это путем создания таблицы и с помощью page-dump или record-dump режимов вместе с --trace увидеть фактические байты, возникающими при чтении записей

источник

2014-11-29 17:48:11 jeremycole

MySQL InnoDB => композиционный ПК и вторичный индекс

ответ

Смежные вопросы