sql >> Database >  >> RDS >> Mysql

mySQL-partitionering van meerdere bestanden versus prestaties van één bestand?

Zoals je al zei -innodb_file_per_table zal beslissen of een tabel in één bestand wordt opgeslagen of (indien gepartitioneerd) in veel bestanden.

Hier zijn enkele voor- en nadelen van elke benadering (niet noodzakelijk een volledige lijst).

Single file per table                    Multiple files per (partitioned) table
--------------------------------------   --------------------------------------
+ System uses less filehandles           - System uses more filehandles
+ One one fsync per second per table     - Possibly many more fsync calls (bottleneck)
  (less fs overhead (journal etc))         (more fs overhead)
+ Single file uses less space overall    - Much larger disk space usage
- Single file fragments badly            + Less fragmentation 
- Optimize table (et al) takes longer    + You can choose to optimize just one file
- One file = one filesystem              + You can put heavy traffic files on a fast fs
                                           (e.g. on a solid state disk)
- Impossible to reclaim disk space       + possible to emergency-reclaim disk space 
  in a hurry (truncate table takes long)   fast (just delete a file)
- ALTER TABLE can use large % of disk-   + rebuilding with ALTER TABLE will use less
  space for temp tables while rebuilding   temp disk space

Over het algemeen zou ik niet raad meerdere bestanden aan.
Als uw werklast echter leidt tot grote fragmentatie en optimize table duurt te lang, het is logisch om meerdere bestanden te gebruiken.

Vergeet het terugwinnen van ruimte
Sommige mensen maken veel ophef over het feit dat in InnoDB-tabelbestanden altijd groeien en nooit krimpen, wat leidt tot verspilde ruimte als rijen worden verwijderd.
Vervolgens bedenken ze schema's om die ruimte terug te winnen, zodat om niet te weinig vrije schijfruimte te hebben. (truncate table x ).
Dit werkt veel sneller met meerdere bestanden, maar dit is allemaal onzin, omdat databases bijna altijd groeien en (bijna) nooit krimpen, dus al dat terugwinnen van ruimte kost veel tijd (CPU en IO) tijdens met uw tafel wordt volledig vergrendeld (lezen en schrijven niet toegestaan).
Alleen om te ontdekken dat uw 90% volle schijf (50% na terugwinning) 99% vol zal zijn na de volgende maand gegevenstoevoegingen.

Pas echter op bij het gebruik van ALTER TABLE...
Denk aan het volgende scenario:
- Schijf is 60% vol.
- database neemt 50% in beslag, andere bestanden nemen 10% in beslag.
Als u een alter table op elke tafel heb je onvoldoende schijfruimte als je alle tabellen in één bestand hebt.
Als je het in meerdere bestanden hebt, zou je geen problemen moeten hebben (behalve een overdosis cafeïne door al dat wachten).




  1. MySQL-fout met dubbele sleutel veroorzaakt een gedeelde vergrendeling op het dubbele indexrecord?

  2. Hoe vervang ik een string door een andere string en bewaar de case in php en mysql?

  3. Geen geldige maand op een INSERT-statement

  4. Gescheiden waarden in een SQL-kolom splitsen in meerdere rijen