MySQL
Indexen en toetsen

Syntaxis

• - Maak een eenvoudige index

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

• - Maak een unieke index

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

• - Drop index

  DROP INDEX indexnaam AAN tbl_naam [ algorithm_option | lock_option ] ...

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

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

Opmerkingen

Maak index

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

Maak een unieke index

Een unieke index voorkomt het invoegen van dubbele gegevens in een tabel. NULL waarden kunnen worden ingevoegd in de kolommen die deel uitmaken van de unieke index (aangezien een NULL waarde per definitie verschilt van elke andere waarde, inclusief een andere NULL waarde)

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

Drop index

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

Maak een samengestelde index

Dit maakt een samengestelde index van beide sleutels, mystring en mydatetime en versnelt query's met beide kolommen in de WHERE component.

CREATE INDEX idx_mycol_myothercol ON my_table(mycol, myothercol)

Let op: De bestelling is belangrijk! Als de zoekopdracht niet beide kolommen in de WHERE component bevat, kan deze alleen de meest linkse index gebruiken. In dit geval, een query met mycol in de WHERE zal de index een query zoeken naar gebruik myothercol zonder ook op zoek naar mycol niet. Bekijk dit blogbericht voor meer informatie.

Opmerking: Vanwege de manier waarop BTREE werkt, moeten kolommen die gewoonlijk in bereiken worden opgevraagd, de meest rechtse waarde hebben. DATETIME kolommen worden bijvoorbeeld DATETIME opgevraagd zoals WHERE datecol > '2016-01-01 00:00:00' . BTREE-indexen verwerken bereiken zeer efficiënt, maar alleen als de kolom die als bereik wordt opgevraagd, de laatste is in de samengestelde index.

AUTO_INCREMENT-toets

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

Hoofdnoten:

• Begint met 1 en wordt automatisch met 1 verhoogd als u het niet op INSERT opgeeft of opgeeft als NULL .
• De id's zijn altijd verschillend van elkaar, maar ...
• Maak geen aannames (geen gaten, opeenvolgend gegenereerd, niet hergebruikt, enz.) Over de waarden van de id anders dan op enig moment uniek te zijn.

Subtiele noten:

• Bij het herstarten van de server wordt de 'volgende' waarde 'berekend' als MAX(id)+1 .
• Als de laatste bewerking vóór het afsluiten of crash was om de hoogste id verwijdert, kan dat id worden hergebruikt (dit is de motor-afhankelijk). Vertrouw dus niet op auto_increments als permanent uniek ; ze zijn alleen uniek op elk moment.
• Zie auto_increment_offset en auto_increment_increment voor multi-master of geclusterde oplossingen.
• Het is OK om iets anders als PRIMARY KEY en gewoon INDEX(id) . (Dit is in sommige situaties een optimalisatie.)
• Het gebruik van de AUTO_INCREMENT als de " PARTITION " is zelden voordelig; doe iets anders.
• Verschillende bewerkingen kunnen waarden "verbranden". Dit gebeurt wanneer ze vooraf waarde (n) toewijzen en deze vervolgens niet gebruiken: INSERT IGNORE (met dup-sleutel), REPLACE (wat DELETE plus INSERT ) en anderen. ROLLBACK is een andere oorzaak voor hiaten in ID's.
• In Replication kunt u niet vertrouwen dat id's in oplopende volgorde bij de slave (s) aankomen. Hoewel id's in opeenvolgende volgorde worden toegewezen, worden InnoDB-instructies in de COMMIT volgorde naar slaven verzonden.