Hur väljer man optimerade datatyper för kolumner [innodb-specifik]?

Kort sammanfattning:

(bara mina åsikter)

1. för e-postadress - VARCHAR(255)
2. för användarnamn - VARCHAR(100) eller VARCHAR(255)
3. för id_username - använd INT (såvida du inte planerar över 2 miljarder användare i ditt system)
4. telefonnummer - INT eller VARCHAR eller kanske CHAR (beror på om du vill lagra formatering)
5. inlägg - TEXT
6. datum - DATE eller DATETIME (inkludera definitivt tider för saker som inlägg eller e-postmeddelanden)
7. pengar - DECIMAL(11,2)
8. övrigt - se nedan

Så långt som att använda InnoDB eftersom VARCHAR är tänkt att vara snabbare, jag skulle inte oroa mig för det, eller hastighet i allmänhet. Använd InnoDB eftersom du behöver göra transaktioner och/eller du vill använda främmande nyckelbegränsningar (FK) för dataintegritet. Dessutom använder InnoDB radnivålåsning medan MyISAM endast använder tabellnivålåsning. Därför kan InnoDB hantera högre nivåer av samtidighet bättre än MyISAM. Använd MyISAM för att använda fulltextindex och för något mindre overhead.

Viktigare för hastigheten än motortypen:lägg index på kolumnerna som du snabbt behöver söka på. Sätt alltid index på dina ID/PK-kolumner, till exempel id_username som jag nämnde.

Mer information:

Här är ett gäng frågor om MySQL-datatyper och databasdesign (varning, fler än du bad om):

• Vilken datatyp ska jag välja?

• Fråga om bordsdesign

• Enum datatyp kontra datatabell i MySQL?

• mysql datatyp för telefonnummer och adress

• Bästa mysql-datatyp för gram, milligram , mikrogram och kilojoule

• MySQL 5-stjärnig betygsdatatyp?

Och ett par frågor om när man ska använda InnoDB-motorn:

• MyISAM kontra InnoDB

• När ska du välja att använda InnoDB i MySQL?

Jag använder bara tinyint för nästan allt (på allvar).

Redigera – Hur man lagrar "inlägg:"

Nedan finns några länkar med mer information, men här är den korta versionen. För att lagra "inlägg" behöver du plats för en lång textsträng. CHAR maxlängden är 255, så det är inte ett alternativ, och naturligtvis CHAR skulle slösa oanvända tecken mot VARCHAR , som är CHAR med variabel längd .

Före MySQL 5.0.3, VARCHAR maxlängden var 255, så du skulle ha TEXT kvar . Men i nyare versioner av MySQL kan du använda VARCHAR eller TEXT . Valet beror på preferenser, men det finns ett par skillnader. VARCHAR och TEXT maxlängden är nu båda 65 535, men du kan ställa in din egen maxlängd på VARCHAR . Låt oss säga att du tror att dina inlägg bara behöver vara max 2000, du kan ställa in VARCHAR(2000) . Om du går in i gränsen kan du ALTER du tabeller senare och stöter den till VARCHAR(3000) . Å andra sidan, TEXT lagrar faktiskt sina data i en BLOB (1). Jag har hört att det kan finnas prestandaskillnader mellan VARCHAR och TEXT , men jag har inte sett några bevis, så du kanske vill undersöka det mer, men du kan alltid ändra den mindre detaljen i framtiden.

Ännu viktigare, att söka i den här "inlägg"-kolumnen med ett fulltextindex istället för LIKE skulle vara mycket snabbare (2). Men du måste använda MyISAM-motorn för att använda fulltextindex eftersom InnoDB inte stöder det . I en MySQL-databas kan du ha en heterogen blandning av motorer för varje tabell, så du behöver bara få din "posts"-tabell att använda MyISAM. Men om du absolut behöver "inlägg" för att använda InnoDB (för transaktioner), ställ in en utlösare för att uppdatera MyISAM-kopian av din "posts"-tabell och använd MyISAM-kopian för alla dina fulltextsökningar.

Se längst ned för några användbara citat.

• MySQL Data Type Chart (föråldrad)

• MySQL-datatyper (föråldrade)

• Kapitel 10. Datatyper (bättre information)

• BLOB- och TEXT-typerna (1)

• 11.9. Fulltextsökningsfunktioner (2)

• 10.4.1. CHAR- och VARCHAR-typerna (3)

Sistligen, här är ett bra inlägg om för- och nackdelar med VARCHAR kontra TEXT. Det talar också om prestandaproblemet:

• VARCHAR(n) övervägs Skadligt