Упражнение 1. Можно ли не объявлять первичный ключ при создании таблицы?
(1) create table user(
name varchar(10)
)engine=innodb;
(2) insert into user values_('shenjian')__;_
(3) insert into user values_('shenjian')__;_
Голос за кадром: При создании таблицы не объявляйте первичный ключ и вставляйте два одинаковых элемента.
Задайте вопрос, выполняйте приведенное выше утверждение непрерывно, результат выполнения:
Ошибка оператора построения таблицы (1)
Оператор вставки B (2) ошибка
Оператор вставки C (3) ошибка
D не сообщает об ошибке
Фактическая операция такая же, как указано выше, поэтому ответ [D не сообщит об ошибке]
InnoDB должен иметь кластеризованный индекс, а записи строк физически сортируются в соответствии с кластеризованным индексом. Должен быть кластеризованный индекс, но это не значит, что должен быть первичный ключ.
(1) Если первичный ключ определен, первичный ключ является кластеризованным индексом;
(2) Если первичный ключ не определен, первый ненулевой (не нулевой) и уникальный (уникальный) столбец является кластеризованным индексом;
(3) Если подходящего столбца нет, скрытый идентификатор строки будет автоматически создан как кластеризованный индекс;
Голос за кадром: Этот пример относится к третьему делу.
Упражнение 2. Не можете ли вы объявить, что первичный ключ не равен нулю при создании таблицы?
(1) create table user(
id int,
name varchar(10),
primary key(id)
)engine=innodb;
(2) insert into user(name) values('shenjian');
(3) insert into user(name) values('shenjian');
Голос за кадром: При построении таблицы не объявляйте ее непустой, а вставляйте два одинаковых элемента.
Задайте вопрос, выполняйте приведенное выше утверждение непрерывно, результат выполнения:
Ошибка оператора построения таблицы (1)
Оператор вставки B (2) ошибка
Оператор вставки C (3) ошибка
_D не сообщает об ошибке
_
Фактическая операция такая же, как указано выше, поэтому ответ: [Ошибка оператора вставки C (3)]
Оператор создания таблицы не может активно устанавливать ненулевой первичный ключ (идентификатор в приведенном выше примере), и InnoDB автоматически добавит ненулевое (не нуль) и уникальное (уникальное) ограничение.
Используйте show create table для просмотра, вы обнаружите, что столбец первичного ключа должен быть ненулевым, а значение по умолчанию равно 0, поэтому:
insert into user(name) values('shenjian');
id по умолчанию 0,первый разУдачная вставка,второй разВставьте нарушение первичного ключа.
_Голос за кадром: _Многие неправильно понимают этот вопрос.
Упражнение 3. Можно ли при создании таблицы выбрать несколько полей в качестве первичного ключа?
(1) create table user(
id int not null,
name varchar(10) not null,
primary key(id, name)
)engine=innodb;
(2) insert into user values(1, 'shenjian');
(3) insert into user values(1, 'zhangsan');
(4) insert into user values(2, 'shenjian');
Голос за кадром: При создании таблицы объявить совместный первичный ключ (а,б), вставить несколько элементов, какой-то повтор, какой-то повтор.
Задайте вопрос, выполняйте приведенное выше утверждение непрерывно, результат выполнения:
Ошибка оператора построения таблицы (1)
Оператор вставки B (2) ошибка
Оператор вставки C (3) ошибка
Оператор вставки D (3) ошибка
E не сообщает об ошибке
Фактическая операция такая же, как указано выше, поэтому ответ: [E не сообщает об ошибке]
Это называетсяСоюз первичного ключа, не требует, чтобы каждый столбец был уникальным, но требует «уникальной комбинации» каждого столбца первичного ключа объединения.
Голос за кадром: совместный индекс, совместный первичный ключ, аналогичный.
Упражнение 4. Можете ли вы активно вставить автоматически увеличивающийся первичный ключ?
(1) create table user(
id int auto_increment,
name varchar(10) not null,
primary key(id)
)engine=innodb;
(2) insert into user(name) values('shenjian');
(3) insert into user_(id, name)_ values_(10,'shenjian')__;_
(4) insert into user(name) values('shenjian');
Голос за кадром: при создании таблицы автоматически увеличивающийся идентификатор является первичным ключом, и вставляются несколько элементов, некоторые из которых включают автоматически увеличивающийся идентификатор, а некоторые нет.
Задайте вопрос, выполняйте приведенное выше утверждение непрерывно, результат выполнения:
Ошибка оператора построения таблицы (1)
Оператор вставки B (2) ошибка
Оператор вставки C (3) ошибка
Оператор вставки D (3) ошибка
E не сообщает об ошибке
Фактическая операция такая же, как указано выше, поэтому ответ: [E не сообщает об ошибке]
В качестве первичного ключа часто используется автоинкрементный идентификатор, при вставке записи строки без указания значения InnoDB автоматически увеличивает его. При этом вы также можете указать значение вручную:
(1) Если указанное вручную значение дублирует существующее значение, возникает конфликт первичного ключа;
(2) Если нет конфликта с существующим значением, вставка выполнена успешно;
(3) Если в будущем в будущем нет указанного значения, он будет продолжать увеличиваться из вставленного вручную стоимость;
Как и в приведенном выше примере, после ручной вставки 10 будущая вставленная гильдия будет начинаться с 11, а в середине ID есть дыра.
Упражнение 5. Можно ли использовать совместный первичный ключ с автоинкрементом при создании таблицы?
(1) create table user(
id int auto_increment,
name varchar(10) not null,
primary key(name, id)
)engine=innodb;
(2) insert into user(name) values('shenjian');
(3) insert into user_(id, name)_ values_(10,'shenjian');_
(4) insert into user(name) values('shenjian');
Голос за кадром: при создании таблицы объявите совместный первичный ключ (a,b), а один из них является автоматически увеличивающимся идентификатором, вставьте несколько элементов, включая автоматически увеличивающийся идентификатор, некоторые нет.
Задайте вопрос, выполняйте приведенное выше утверждение непрерывно, результат выполнения:
Ошибка оператора построения таблицы (1)
Оператор вставки B (2) ошибка
Оператор вставки C (3) ошибка
Оператор вставки D (3) ошибка
_E не сообщает об ошибке
_
Фактическая операция такая же, как указано выше, поэтому ответ: [оператор построения таблицы (1) сообщает об ошибке]
Это не означает, что самоувеличивающийся идентификатор нельзя использовать в качестве общего первичного ключа, но если он используется в качестве общего первичного ключа, его необходимо поместить в первый столбец.
primary key(name, id_)_
изменить на
primary key(id, name)
Его можно успешно выполнить.
_Голос за кадром: _Многие неправильно понимают этот вопрос.
Суммировать
Первый: может ли InnoDB не объявлять первичный ключ при создании таблицы?
Первичный ключ объявлять не обязательно, но должен быть кластеризованный индекс:
(1) существует первичный ключ, представляющий собой кластеризованный индекс;
(2) первичный ключ отсутствует, а первый ненулевой уникальный столбец представляет собой кластеризованный индекс;
(3) Нет подходящего столбца, row-id — это кластеризованный индекс;
Первичный ключ и кластерный индекс — это не одно и то же, не путайте.
Второе: может ли InnoDB не объявлять, что первичный ключ не пуст при создании таблицы?
Вы не можете объявить, что первичный ключ не нулевой, и ненулевой лимит будет добавлен автоматически.
Третье: при создании таблицы в InnoDB вы можете выбрать несколько полей в качестве первичного ключа?
Вы можете использовать комбинированный первичный ключ, а комбинированный столбец уникален.
Четвертое: когда InnoDB выполняет вставку, может ли она активно вставлять самоувеличивающийся первичный ключ?
Можно указать значения для автоинкрементных столбцов, но это может привести к дырам.
Пять: Может ли InnoDB использовать первичный ключ Union Auto-Starretion при создании таблицы?
Да, но автоматически увеличивающийся идентификатор должен находиться в первом столбце первичного ключа объединения.
Я надеюсь, что у всех есть более систематическое понимание первичного ключа.
Путь архитектора- Делитесь техническими идеями
Статьи по Теме:
"Буферный пул (буферный пул), полностью понимаю!》
"Буфер записи (буфер изменения), полностью разобрался!》
[DCEEA], вы правильно поняли?