In MySQL, quando si eliminano record da una tabella, lo spazio è riassegnato automaticamente. E ‘come uno spazio vuoto e formando gli allegati nuovi vantaggio.

Il problema è che se una tabella di eseguire molte operazioni di DELETE, lo spazio fisico del tavolo sarà sempre più frammentato e il rendimento è ridotto.

Nel MyISAM e InnoDB, OPTIMIZE TABLE comando disponibile ad effettuare l’ottimizzazione su qualsiasi tabella che, tra l’altro, esegue una deframmentazione automatica del tavolo.

Si consiglia vivamente di utilizzare questo comando regolarmente in particolare su tabelle che sono più le dichiarazioni di smaltimento dei record.

Per precauzione, di tenere presente che durante l’esecuzione, naturalmente, la tabella è bloccato. Si deve ricordare quando si sta per l’utilizzo con tabelle di grandi dimensioni e occupato.

La sintassi è la seguente:

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE mi_tabla1 [, mi_tabla2] ...;

Per fare un tavolo di ottimizzazione frammentati possono essere selezionati per avere spazio libero, probabilmente a causa di DELETE:

SELECT TABLE_SCHEMA,TABLE_NAME
FROM TABLES WHERE TABLE_SCHEMA NOT IN ("information_schema","mysql") AND
Data_free > 0

Un semplice script per deframmentare in automatico : 

#!/bin/bash

# Get a list of all fragmented tables
FRAGMENTED_TABLES="$( mysql -e 'use information_schema; SELECT TABLE_SCHEMA,TABLE_NAME \
FROM TABLES WHERE TABLE_SCHEMA NOT IN ("information_schema","mysql") AND \
Data_free > 0' | grep -v "^+" | sed "s,\t,.," )"

for fragment in $FRAGMENTED_TABLES; do
   database="$( echo $fragment | cut -d. -f1 )"
   table="$( echo $fragment | cut -d. -f2 )"
   [ $fragment != "TABLE_SCHEMA.TABLE_NAME" ] && mysql -e "USE $database;\
   OPTIMIZE TABLE $table;" > /dev/null 2>&1
done

Cosa succede se si fa una bella insert sul nostro database mysql slave?
Due cose :

1. Lo slave server si disallinea
2. Il sistemista bestemmia 

Per controllore lo stato dello slave bisogna lanciare dallo slave :

mysql> show slave status\G 

Lo Slave utilizza piu’ thread. Il primo e’ una connessione remota al Master ed ha il compito di raccogliere i dati dal bin-log (BinLog Dump) ed e’ sempre attivo. Gli altri thread sono locali ed hanno il compito di ricevere il contenuto del bin-log (Slave I/O) e di applicarlo alla base dati (Slave SQL). In caso d’errore nell’inserimento dei dati il thread Slave SQL si interrompe mentre lo Slave I/O continua a raccogliere i dati dal Master. Con show slave status\G si ottiene l’indicazione dell’errore occorso; una volta corretto il problema la replicazione riprende dal punto in cui si era interrotta applicando il relay-log. 

Per risolvere il problema numero 1 bisogna seguire questa facile guida :

1. Stoppare sugli SLAVE SERVER il servizio di replica :

mysql> stop slave;

2. Lokkare le tabelle sul MYSQL MASTER (occhio a non uscire da mysql altrimenti questo comando viene flushato)

mysql> FLUSH TABLES WITH READ LOCK;

3. Effettuare un dump completo e copiarli sullo/i SLAVE/s :

mysqldump --all-database > databases.sql -u root -p 

4. Restore DB sugli SLAVE

mysql -u root -p databases.sql 

5. Controllare lo stato del MYSQL MASTER per vedere fino a che punto è arrivata il transaction bin log : (in un altra sessione ssh, vedi punto 2)

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000059 | 17908642 |              |                  |
+------------------+----------+--------------+------------------+

6. Riattivare il MYSQL SLAVE

CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000059', MASTER_LOG_POS = 17148864;

7. Riattivare lo slave

mysql> start slave;

8. Riattivare il MYSQL MASTER in scrittura

UNLOCK TABLES;