MySQL
Индексы и ключи

Синтаксис

• - Создать простой индекс

  CREATE INDEX index_name ON table_name ( column_name1 [, column_name2 , ...])

• - Создать уникальный индекс

  CREATE UNIQUE INDEX index_name ON table_name ( column_name1 [, column_name2 , ...]

• - Индекс падения

  DROP INDEX index_name ON tbl_name [ algorithm_option | lock_option ] ...

  algorithm_option: ALGORITHM [=] {DEFAULT | INPLACE | COPY}

  lock_option: LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}

замечания

Создать индекс

-- Create an index for column 'name' in table 'my_table'
CREATE INDEX idx_name ON my_table(name);

Создать уникальный индекс

Уникальный индекс предотвращает вставку дублированных данных в таблицу. Значения NULL могут быть вставлены в столбцы, которые составляют часть уникального индекса (так как по определению значение NULL отличается от любого другого значения, включая другое значение NULL )

-- Creates a unique index for column 'name' in table 'my_table'
CREATE UNIQUE INDEX idx_name ON my_table(name);

Индекс падения

-- Drop an index for column 'name' in table 'my_table'
DROP INDEX idx_name ON my_table;

Создание комбинированного индекса

Это создаст составной индекс обоих ключей, mystring и mydatetime и ускорит запросы с обоими столбцами в WHERE .

CREATE INDEX idx_mycol_myothercol ON my_table(mycol, myothercol)

Примечание: порядок важен! Если поисковый запрос не включает оба столбца в WHERE , он может использовать только самый левый индекс. В этом случае запрос с mycol в WHERE будет использовать индекс, поиск запроса для myothercol без также ищу mycol не будет. Для получения дополнительной информации ознакомьтесь с этим сообщением в блоге .

Примечание. В связи с работой BTREE столбцы, которые обычно запрашиваются в диапазонах, должны иметь самое правое значение. Например, столбцы DATETIME обычно запрашиваются как WHERE datecol > '2016-01-01 00:00:00' . Индексы BTREE обрабатывают диапазоны очень эффективно, но только если столбец, запрашиваемый как диапазон, является последним в составном индексе.

Кнопка AUTO_INCREMENT

CREATE TABLE (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    ...
    PRIMARY KEY(id),
    ...  );

Основные примечания:

• Начинается с 1 и увеличивается на 1 автоматически, когда вы не можете указать его на INSERT или указать его как NULL .
• Иды всегда отличаются друг от друга, но ...
• Не делайте никаких предположений (без пробелов, последовательно генерируемых, не повторно используемых и т. Д.) О значениях id, отличных от уникальных в любой данный момент времени.

Тонкие ноты:

• При перезапуске сервера значение «next» «вычисляется» как MAX(id)+1 .
• Если последняя операция перед отключением или сбоем заключалась в удалении самого высокого идентификатора, этот идентификатор может быть повторно использован (это зависит от двигателя). Таким образом, не доверяйте auto_increments, чтобы быть постоянно уникальными ; они уникальны в любой момент.
• Для многомашинных или кластерных решений см. auto_increment_offset и auto_increment_increment .
• Это нормально, если что-то другое, как PRIMARY KEY и просто делать INDEX(id) . (Это оптимизация в некоторых ситуациях.)
• Использование AUTO_INCREMENT в качестве «ключа PARTITION » редко полезно; сделать что-то другое.
• Различные операции могут «записывать» значения. Это происходит, когда они предварительно выделяют значения (-ы), а затем не используют их: INSERT IGNORE (с ключом dup), REPLACE (который DELETE плюс INSERT ) и другие. ROLLBACK - еще одна причина для пробелов в идентификаторах.
• В репликации вы не можете доверять идентификаторам, чтобы достигнуть ведомого (-ов) в порядке возрастания. Хотя идентификаторы назначаются в последовательном порядке, операторы InnoDB отправляются COMMIT порядке COMMIT .