Dopo l'installazione iniziale di un database MySQL, i responsabili IT potrebbero rilevare che le prestazioni I / O dei loro server hanno iniziato a peggiorare.

Uno dei motivi più comuni è la frammentazione del disco rigido. Se la tua particolare installazione utilizza un numero elevato di chiamate casuali, questo spesso porterà alla frammentazione su tutta la memoria installata.

Avere un regime di deframmentazione è essenziale per evitare questo problema di prestazioni.

Una delle aree chiave per cercare la frammentazione è nelle tabelle SQL. Ciò può spesso accadere con l'eliminazione casuale e inserimenti che frammentano sempre più una tabella fino a quando non si verifica un calo delle prestazioni nel server host.

Inoltre, se si notano aumenti nell'utilizzo dello spazio su disco che non possono essere spiegati da altre azioni intraprese, è probabile che sia colpa di una tabella frammentata, poiché tendono a occupare più spazio disponibile su disco.

Primo passo

Le tabelle più comuni per sperimentare la frammentazione saranno InnoDB e MyISAM. Per gli amministratori di sistema con il compito di capire perché le loro prestazioni del database sono state erose, concentrarsi sul primo tipo di tabella in primo luogo sarà sempre un buon primo passo.

Questo perché la tabella InnoDB contrassegna tutti i dati scritti come cancellati che il blocco rimane vuoto e non viene sovrascritto con i nuovi dati. Naturalmente, nel corso del tempo questo gonfia artificialmente la tabella con un problema corrispondente con le prestazioni.

Generalmente, l'esecuzione della routine 'Optimize Table' ricostruirà la tabella e il suo indice. Si noti che la tabella verrà bloccata mentre viene eseguito questo comando.

Inoltre, gli amministratori di sistema dovrebbero essere consapevoli del fatto che le tabelle secondarie potrebbero avere ancora livelli elevati di frammentazione anche dopo che la routine è stata completata.

Tuttavia, molti amministratori di sistema sono più intelligenti con i loro regimi di deframmentazione, poiché si rendono conto che alcune tabelle avranno più traffico di altre. Eseguire una deframmentazione complessa tramite la tabella Optimize Table può essere inefficiente.

Una conseguenza di ciò è che ogni istanza genera un log delle transazioni, che può richiedere sempre più tempo per eseguire il backup. Inoltre, controllare il livello effettivo di frammentazione su ciascun indice prima di iniziare può essere spesso molto rivelatore.

L'impostazione di un livello minimo di frammentazione dell'indice prima della deframmentazione assicurerà che non si eseguano deframmentazioni inutili sui server.

Basso fattore di riempimento

Gli amministratori di sistema dovrebbero anche pensare a come hanno impostato il loro database. In alcuni casi questo includerà un fattore di riempimento basso, che accelera le scritture sul database ma rallenta al contrario le letture.

Possono anche vedere i vantaggi delle prestazioni se possono memorizzare nella cache i loro database.

Se ciò non è possibile, guarda come il database è distribuito sui dischi rigidi installati. Se si dispone di storage condiviso su un'installazione di Dell PowerEdge, ad esempio, pensa a come si potrebbe semplificare questo per ridurre la quantità di accessi casuali che il database deve eseguire su un determinato numero di dischi rigidi.

Oltre a concentrarsi sulle tabelle stesse del database, i responsabili IT dovrebbero anche pensare alla manutenzione degli hard disk fisici utilizzati dai loro server. Una deframmentazione del sistema operativo ad intervalli regolari dovrebbe offrire una migliore aspettativa di vita per l'hardware e consentire inoltre alle applicazioni installate di vedere aumenti delle prestazioni.