MySQL
Index och nycklar

Syntax

• - Skapa enkelt index

  SKAPA INDEX indexnamn PÅ tabellnamn ( kolumnnamn1 [, kolumnnamn2 , ...])

• - Skapa unikt index

  SKAPA UNIK INDEX indexnamn PÅ tabellnamn ( kolumnnamn1 [, kolumnnamn2 , ...]

• - Drop index

  DROP INDEX indexnamn PÅ tbl_namn [ algoritm_option | lock_option ] ...

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

  lock_option: LOCK [=] {DEFAULT | INGEN | DELAD | EXKLUSIVT}

Anmärkningar

Skapa index

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

Skapa unikt index

Ett unikt index förhindrar att duplicerade data införs i en tabell. NULL värden kan infogas i kolumnerna som utgör en del av det unika indexet (eftersom, per definition, ett NULL värde skiljer sig från något annat värde, inklusive ett annat NULL värde)

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

Släpp index

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

Skapa sammansatt index

Detta skapar ett sammansatt index av båda nycklarna, mystring och mydatetime och påskyndar frågor med båda kolumnerna i WHERE klausulen.

CREATE INDEX idx_mycol_myothercol ON my_table(mycol, myothercol)

Obs! Beställningen är viktig! Om sökfrågan inte innehåller båda kolumnerna i WHERE klausulen kan den bara använda det vänstra indexet. I det här fallet kommer en fråga med mycol i WHERE att använda indexet, en fråga som söker efter myothercol utan att också söka efter mycol kommer inte . För mer information, kolla in detta blogginlägg .

Obs: På grund av hur BTREE arbetar, bör kolumner som vanligtvis fråges i intervaller gå längst till höger. Till exempel DATETIME kolumner vanligtvis som WHERE datecol > '2016-01-01 00:00:00' . BTREE-indexhandtaget sträcker sig mycket effektivt men bara om kolumnen som fråges som ett intervall är den sista i kompositindex.

AUTO_INCREMENT-tangent

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

Huvudanmärkningar:

• Börjar med 1 och steg med 1 automatiskt när du inte anger det på INSERT eller anger det som NULL .
• ID: er skiljer sig alltid från varandra, men ...
• Anta inga antaganden (inga luckor, genereras i följd, inte återanvändas, osv.) Om värdena på iden annat än att vara unik vid ett visst ögonblick.

Subtila anteckningar:

• Vid omstart av servern beräknas 'nästa' värde som MAX(id)+1 .
• Om den senaste åtgärden innan avstängning eller kraschen var att ta bort den högsta id kan att id återanvändas (detta är motorberoende). Så lita inte på att auto_inkrement är permanent unika ; de är bara unika när som helst.
• För lösningar med flera master eller kluster, se auto_increment_offset och auto_increment_increment .
• Det är OK att ha något annat som PRIMARY KEY och helt enkelt göra INDEX(id) . (Detta är en optimering i vissa situationer.)
• Att använda AUTO_INCREMENT som " PARTITION nyckel" är sällan fördelaktigt; gör något annorlunda.
• Olika operationer kan "bränna" värden. Detta händer när de fördelar värde (er) och sedan inte använder dem: INSERT IGNORE (med dup-nyckel), REPLACE (som är DELETE plus INSERT ) och andra. ROLLBACK är en annan orsak till luckor i ID: er.
• I replikering kan du inte lita på id: er för att komma fram till slaven i stigande ordning. Även om ID: er tilldelas i ordning i följd, skickas InnoDB-uttalanden till slavar i COMMIT ordning.