Hvordan vælger man optimerede datatyper til kolonner [innodb-specifik]?

Kort resumé:

(bare mine meninger)

for e-mailadresse - VARCHAR(255)
for brugernavn - VARCHAR(100) eller VARCHAR(255)
til id_brugernavn - brug INT (medmindre du planlægger over 2 milliarder brugere i dit system)
telefonnumre - INT eller VARCHAR eller måske CHAR (afhænger af, om du vil gemme formatering)
indlæg - TEXT
datoer - DATE eller DATETIME (inkluder bestemt tidspunkter for ting som indlæg eller e-mails)
penge - DECIMAL(11,2)


 diverse - se nedenfor

 
 Så vidt som ved at bruge InnoDB fordi VARCHAR formodes at være hurtigere, det ville jeg ikke bekymre mig om, eller hastighed generelt. Brug InnoDB, fordi du skal udføre transaktioner og/eller du vil bruge fremmednøglebegrænsninger (FK) til dataintegritet. InnoDB bruger også rækkeniveaulåsning, mens MyISAM kun bruger tabelniveaulåsning. Derfor kan InnoDB håndtere højere niveauer af samtidighed bedre end MyISAM. Brug MyISAM til at bruge fuldtekstindekser og til noget mindre overhead.
 
 Vigtigere for hastigheden end motortypen:Sæt indekser på de kolonner, som du hurtigt skal søge på. Sæt altid indekser på dine ID/PK-kolonner, såsom id_username, som jeg nævnte.
 
 Flere detaljer: 
 
 Her er en masse spørgsmål om MySQL-datatyper og databasedesign (advarsel, mere end du bad om):
   
 Hvilken datatype skal jeg vælge?
 
 
  
 Spørgsmål til borddesign
 
 
  
 Enum datatype versus tabel over data i MySQL? 
 
 
  
 mysql datatype for telefonnummer og adresse
 
 
  
 Bedste mysql-datatype for gram, milligram , mikrogram og kilojoule
 
 
  
 MySQL 5-stjernet vurderingsdatatype?
 
 
 
 
 Og et par spørgsmål om, hvornår du skal bruge InnoDB-motoren:
   
 MyISAM versus InnoDB
 
 
  
 Hvornår skal du vælge at bruge InnoDB i MySQL?
 
 
 
 
 Jeg bruger bare tinyint for næsten alt (seriøst). 
 
 Rediger - Sådan gemmer du "indlæg:" 
 
 Nedenfor er nogle links med flere detaljer, men her er den korte version. For at gemme "indlæg" har du brug for plads til en lang tekststreng. CHAR max længde er 255, så det er ikke en mulighed, og selvfølgelig CHAR ville spilde ubrugte tegn versus VARCHAR , som er variabel længde CHAR .
 
 Før MySQL 5.0.3, VARCHAR maks. længde var 255, så du ville stå tilbage med TEXT . I nyere versioner af MySQL kan du dog bruge VARCHAR eller TEKST . Valget afhænger af præference, men der er et par forskelle. VARCHAR og TEKST max længde er nu begge 65.535, men du kan indstille din egen max på VARCHAR . Lad os sige, at du tror, at dine indlæg kun skal være 2000 maks., du kan indstille VARCHAR(2000) . Hvis du hver gang løber ind i grænsen, kan du ALTER du tabel senere og støder den til VARCHAR(3000) . På den anden side, TEXT gemmer faktisk sine data i en BLOB (1). Jeg har hørt, at der kan være ydeevneforskelle mellem VARCHAR og TEKST , men jeg har ikke set noget bevis, så det kan være en god ide at se nærmere på det, men du kan altid ændre den lille detalje i fremtiden.
 
 Endnu vigtigere er det at søge i denne "indlæg"-kolonne ved hjælp af et fuldtekstindeks i stedet for LIKE ville være meget hurtigere (2). Men du skal bruge MyISAM-motoren for at bruge fuldtekstindeks, fordi InnoDB ikke understøtter det . I en MySQL-database kan du have en heterogen blanding af motorer for hver tabel, så du skal blot få din "posts"-tabel til at bruge MyISAM. Men hvis du absolut har brug for "indlæg" for at bruge InnoDB (til transaktioner), så opsæt en trigger for at opdatere MyISAM-kopien af din "indlæg"-tabel og brug MyISAM-kopien til alle dine fuldtekstsøgninger.
 
 Se bunden for nogle nyttige citater. 
   
 MySQL-datatypediagram (forældet)
 
 
  
 MySQL-datatyper (forældede)
 
 
  
 Kapitel 10. Datatyper (bedre detaljer)
 
 
  
 BLOB- og TEKST-typerne (1)
 
 
  
 11.9. Fuldtekstsøgningsfunktioner (2)
 
 
  
 10.4.1. CHAR- og VARCHAR-typerne (3)
 
 
 
 
 Til sidst er her et godt indlæg om fordele og ulemper ved VARCHAR versus TEXT. Det taler også om ydeevneproblemet: 
  VARCHAR(n) overvejes Skadelig