sql >> Database >  >> RDS >> Mysql

Hoe kies je geoptimaliseerde datatypes voor kolommen [innodb-specifiek]?

Korte samenvatting:

(alleen mijn mening)

  1. voor e-mailadres - VARCHAR(255)
  2. voor gebruikersnaam - VARCHAR(100) of VARCHAR(255)
  3. voor id_username - gebruik INT (tenzij u meer dan 2 miljard gebruikers in uw systeem plant)
  4. telefoonnummers - INT of VARCHAR of misschien CHAR (afhankelijk van of je de opmaak wilt opslaan)
  5. posts - TEXT
  6. datums - DATE of DATETIME (vermeld zeker tijden voor zaken als berichten of e-mails)
  7. geld - DECIMAL(11,2)
  8. overig - zie hieronder

Wat betreft het gebruik van InnoDB omdat VARCHAR zou sneller moeten zijn, daar zou ik me geen zorgen over maken, of snelheid in het algemeen. Gebruik InnoDB omdat u transacties moet doen en/of u externe sleutelbeperkingen (FK) wilt gebruiken voor gegevensintegriteit. Ook gebruikt InnoDB vergrendeling op rijniveau, terwijl MyISAM alleen vergrendeling op tabelniveau gebruikt. Daarom kan InnoDB hogere niveaus van gelijktijdigheid beter aan dan MyISAM. Gebruik MyISAM om full-text indexen te gebruiken en voor wat minder overhead.

Belangrijker voor snelheid dan het type motor:plaats indexen op de kolommen waarop u snel moet zoeken. Plaats altijd indexen op uw ID/PK-kolommen, zoals de id_username die ik noemde.

Meer details:

Hier zijn een aantal vragen over MySQL-datatypes en database-ontwerp (waarschuwing, meer dan waar je om vroeg):

En een paar vragen over wanneer de InnoDB-engine moet worden gebruikt:

Ik gebruik gewoon tinyint voor bijna alles (serieus).

Bewerken - Hoe "posts:" op te slaan

Hieronder staan ​​enkele links met meer details, maar hier is de korte versie. Voor het opslaan van "berichten" heb je ruimte nodig voor een lange tekenreeks. CHAR max lengte is 255, dus dat is geen optie, en natuurlijk CHAR zou ongebruikte tekens verspillen versus VARCHAR , wat een variabele lengte is CHAR .

Voorafgaand aan MySQL 5.0.3, VARCHAR max lengte was 255, dus je zou achterblijven met TEXT . In nieuwere versies van MySQL kunt u echter VARCHAR . gebruiken of TEXT . De keuze komt neer op voorkeur, maar er zijn een paar verschillen. VARCHAR en TEXT max lengte is nu beide 65.535, maar je kunt je eigen max instellen op VARCHAR . Stel dat u denkt dat uw berichten maximaal 2000 hoeven te zijn, u kunt VARCHAR(2000) instellen . Als u elk de limiet tegenkomt, kunt u ALTER je tafel later en stoot het naar VARCHAR(3000) . Aan de andere kant, TEXT slaat zijn gegevens daadwerkelijk op in een BLOB (1). Ik heb gehoord dat er prestatieverschillen kunnen zijn tussen VARCHAR en TEXT , maar ik heb geen bewijs gezien, dus misschien wil je daar meer naar kijken, maar je kunt dat kleine detail in de toekomst altijd veranderen.

Wat nog belangrijker is, het doorzoeken van deze "post"-kolom met behulp van een Full-Text Index in plaats van LIKE zou veel sneller zijn (2). u moet echter de MyISAM-engine gebruiken om de volledige tekstindex te gebruiken, omdat InnoDB dit niet ondersteunt . In een MySQL-database kunt u voor elke tabel een heterogene mix van engines hebben, dus u hoeft alleen maar uw "posts"-tabel MyISAM te laten gebruiken. Als u echter absoluut "posts" nodig heeft om InnoDB (voor transacties) te gebruiken, stel dan een trigger in om de MyISAM-kopie van uw "posts"-tabel bij te werken en gebruik de MyISAM-kopie voor al uw zoekopdrachten in volledige tekst.

Zie onderaan voor enkele nuttige citaten.

Ten slotte is hier een geweldige post over de voor- en nadelen van VARCHAR versus TEXT. Het spreekt ook over het prestatieprobleem:



  1. MySQL komt overeen met 2 van de 5 velden

  2. MySQL:INT converteren naar DATETIME

  3. Hoe maak je LEFT JOIN met SELECT subquery met behulp van QueryBuilder in Doctrine 2?

  4. Selecteer rijen uit een tabel waar een rij in een andere tabel met dezelfde id een bepaalde waarde heeft in een andere kolom