Hai aperto XAMPP, cliccato su Start accanto a MySQL e dopo due secondi il pulsante è tornato rosso. Nessun messaggio, nessun errore, solo il pannello che ti fissa. Se ti sta succedendo proprio adesso, sappi che XAMPP non avvia MySQL nel 90% dei casi per un motivo preciso: la porta 3306 è già occupata da qualcun altro. Non è un bug di XAMPP, è un conflitto di risorse.
Il restante 10% è colpa di file InnoDB danneggiati, un servizio Windows fantasma che si avvia prima di te, oppure l’antivirus che mette in quarantena mysqld.exe senza avvisarti. Quella che segue è la procedura reale, in ordine di probabilità, aggiornata al 2026. Non è la solita lista copiata da un forum del 2012.
Porta 3306 occupata: la causa numero uno di XAMPP MySQL che non parte
MySQL su XAMPP ascolta di default sulla porta 3306. Se un altro programma la sta usando, mysqld.exe non riesce a fare il bind e muore in silenzio. Il pulsante si spegne e tu non capisci niente. Questa è la prima cosa da verificare se XAMPP non avvia MySQL.
Apri il prompt dei comandi come amministratore e lancia:
netstat -ano | findstr :3306
Se compare una riga con LISTENING, hai trovato il colpevole. L’ultimo numero a destra è il PID del processo. Con tasklist | findstr [PID] capisci chi è. Nella mia esperienza il colpevole più frequente è un’installazione precedente di MySQL Community, SQL Server Express di Visual Studio, oppure un’altra istanza di XAMPP rimasta attiva. Anche software di backup aziendali e VPN aziendali si piazzano sulla 3306 senza chiedere permesso.
Hai due strade: killare il processo con taskkill /PID numero /F, oppure cambiare la porta di MySQL in XAMPP. Per la seconda opzione clicca su Config → my.ini nel pannello di controllo, cerca la voce port=3306 e sostituiscila con 3307. Riavvia MySQL e aggiorna anche phpMyAdmin, altrimenti non si connette più.
Servizio Windows duplicato: il killer silenzioso che blocca XAMPP MySQL
Se in passato hai installato MySQL come servizio di sistema, questo parte automaticamente all’avvio di Windows e si prende la porta 3306 prima ancora che XAMPP ci provi. Ecco perché XAMPP non avvia MySQL in modo intermittente: se il servizio è impostato su avvio ritardato, a volte XAMPP ce la fa, altre no.
Apri services.msc con Win+R, cerca “MySQL” e controlla lo stato. Se è avviato, fermalo e imposta il tipo di avvio su “Manuale”. Poi torna su XAMPP e premi Start. Nel 99% dei casi la spia diventa verde. Fai attenzione anche alle voci MySQL80 o MySQL57, presenti sui PC dove hai installato MySQL Installer per altri motivi. Blocca l’avvio automatico e chiudi la questione una volta per tutte.
Leggi il log degli errori: ti dice lui cosa non va
Nessuno lo fa mai, ma è il passaggio più utile di tutti quando XAMPP non avvia MySQL. Vai in C:xamppmysqldata e apri mysql_error.log con Blocco note. Le ultime righe sono quelle che contano davvero.
Se leggi InnoDB: Cannot allocate memory hai un problema di RAM o di buffer configurato male nel my.ini. Se leggi InnoDB: File .ibdata1: ‘open’ returned OS error hai i file dati corrotti o con permessi sbagliati. Se leggi Can’t create/write to file è quasi sempre l’antivirus (Kaspersky, Avast, Defender con ransomware protection attiva) che sta mettendo in quarantena la cartella data.
Soluzione rapida per l’antivirus: aggiungi C:xampp come eccezione. Non disattivare tutto, basta escludere la cartella. Funziona anche per gli aggiornamenti di WordPress in locale che a volte falliscono senza motivo apparente.
File InnoDB corrotti: la procedura di recupero che pochi spiegano
Se il log conferma che ibdata1 o ib_logfile sono danneggiati, il recupero pulito è questo: rinomina la cartella data in data_old (non cancellarla), crea una nuova cartella data vuota e lascia che XAMPP la ricostruisca al primo avvio. Perderai i database locali, ma recuperi MySQL in due minuti.
Se i dati ti servono, la strada è più lunga: copia la cartella mysql e le cartelle dei singoli database da data_old nella nuova data, e avvia. Se non basta, ti serve innodb_force_recovery impostato a 1 o 2 nel my.ini, solo per fare un dump con mysqldump e poi ricaricare tutto su un’istanza pulita. Sì, è noioso, ma è l’unico modo che funziona davvero quando le tabelle InnoDB sono compromesse e XAMPP non avvia MySQL.
Errori di sintassi nel my.ini: quando una virgola blocca tutto
Hai toccato il file di configurazione per aumentare max_connections, cambiare innodb_buffer_pool_size o qualcos’altro? Un solo carattere sbagliato fa fallire l’avvio senza avvisi. MySQL è fatto così: non ti dice “riga 27 errore”, semplicemente non parte.
Riapri my.ini e controlla che ogni sezione sia sotto [mysqld], [client] o [mysql], che non ci siano parametri duplicati e che i percorsi usino gli slash corretti. Se hai dubbi, fai un backup del tuo my.ini e ripristina quello di default dalla cartella xamppmysqlbackup.
Firewall, permessi e posizione di installazione: gli ultimi sospetti
Il firewall di Windows raramente blocca MySQL su localhost, ma se hai installato un firewall di terze parti (Comodo, GlassWire, ZoneAlarm) la regola d’ingresso per mysqld.exe potrebbe non esistere. Aggiungila manualmente e consenti sia il traffico privato che quello pubblico.
Ultimo controllo: XAMPP deve girare come amministratore. Se lo hai installato in C:Programmi invece che in C:xampp, Windows applica permessi restrittivi sulla cartella data e MySQL non riesce a scrivere. Sposta XAMPP in C:xampp, che è la posizione ufficiale supportata, e i problemi di permessi spariscono.
Il riavvio del PC, che sembra il consiglio più banale del mondo, in realtà ha senso in un caso specifico: quando hai terminato un processo che teneva la porta occupata, ma il socket è rimasto in stato TIME_WAIT. In quel caso solo un riavvio lo libera subito.
Se dopo tutto questo XAMPP non avvia MySQL, disinstalla XAMPP, cancella manualmente ogni residuo in C:xampp e reinstalla l’ultima versione. A volte la soluzione più veloce è smettere di combattere contro un’installazione incasinata.
