Passo 1: verificare l\u2019accesso al sito e al back-office (indizio prezioso)<\/h2>\n
Primo riflesso: testate sia la home page sia \/wp-admin\/<\/em>. Se il front-end \u00e8 KO ma l\u2019admin si apre, il problema pu\u00f2 essere parziale (cache, tabella specifica, sovraccarico). Se \u00e8 tutto KO, orientatevi piuttosto verso un problema di connessione globale (credenziali, server DB down, guasto dell\u2019hosting).<\/p>\n Altro indizio: alcuni host mostrano una pagina di errore diversa o un messaggio del tipo Error establishing a database connection pi\u00f9 grezzo. Annotate l\u2019ora, il contesto (aggiornamento, picco di traffico, migrazione) e qualsiasi cambiamento recente (plugin, tema, manipolazione DNS, ripristino di backup).<\/p>\n Nella maggior parte dei casi, l\u2019errore deriva da un parametro errato in wp-config.php<\/em>. Le costanti da verificare sono:<\/p>\n DB_NAME<\/strong> (nome del database), DB_USER<\/strong> (utente), DB_PASSWORD<\/strong> (password), DB_HOST<\/strong> (host del server del database).<\/p>\n Su molti hosting, DB_HOST<\/em> vale localhost<\/em>. Ma non \u00e8 universale: pu\u00f2 trattarsi di un IP, di un hostname interno (es. mysqlXX<\/em>), o di un socket specifico. Dopo una migrazione, un cambio di offerta o il passaggio a un ambiente gestito, questo valore pu\u00f2 cambiare.<\/p>\n Confrontate i valori di wp-config.php<\/em> con quelli indicati nel pannello di controllo dell\u2019host (database, utente, password, host). Se avete recentemente rigenerato una password MySQL, non dimenticate di riportarla qui. Basta un solo refuso.<\/p>\n Se avete bisogno di una guida passo-passo lato hosting, potete consultare Risolvere l\u2019Errore Errore durante la connessione al database di \u2026<\/a> che dettaglia le verifiche tipiche e i percorsi pi\u00f9 comuni nelle interfacce degli host.<\/p>\n L\u2019idea \u00e8 semplice: determinare se il problema proviene da WordPress o dal database stesso. Se riuscite a connettervi a MySQL con le stesse credenziali, allora WordPress fallisce per una ragione secondaria (risorse, corruzione, plugin, ecc.). Se la connessione fallisce, il problema \u00e8 proprio a livello di accessi\/server.<\/p>\n Metodi possibili a seconda del vostro accesso:<\/p>\n 1) Tramite phpMyAdmin: provate ad aprire il database e a scorrere le tabelle. Scoprite le nostre offerte di manutenzione WP<\/a><\/p>\n<\/div>\n Se phpMyAdmin mostra un errore di autenticazione, siete di fronte a una coppia user\/password errata, a un user senza permessi, o a un database inesistente. Se phpMyAdmin non si carica o impiega moltissimo tempo, il servizio potrebbe essere guasto o saturo.<\/p>\n Quando le credenziali sono corrette, l\u2019errore appare spesso durante un\u2019indisponibilit\u00e0 temporanea: riavvio di MySQL, manutenzione, sovraccarico CPU\/RAM, troppe connessioni simultanee, disco pieno, o limite di processi raggiunto su un hosting condiviso.<\/p>\n Segni indicativi:<\/p>\n \u2013 Il problema si verifica all\u2019improvviso senza modifiche recenti. In questo scenario, verificate lo stato dell\u2019host, gli incidenti in corso e le metriche se avete accesso (CPU, RAM, I\/O, numero di connessioni). Un\u2019ottimizzazione o il passaggio a un\u2019offerta pi\u00f9 robusta pu\u00f2 essere necessario se l\u2019errore si ripresenta regolarmente.<\/p>\n Se potete modificare wp-config.php<\/em>, potete attivare temporaneamente il debug per ottenere indizi (da usare con cautela in produzione). L\u2019obiettivo non \u00e8 mostrare dettagli ai visitatori, ma registrare gli errori.<\/p>\n In pratica, si preferisce attivare un log (file) piuttosto che la visualizzazione. Una volta raccolte le informazioni, ripristinate i parametri iniziali per evitare qualsiasi fuga di informazioni.<\/p>\n Oltre al debug, pensate anche ai log del server (error_log, log PHP-FPM, log MySQL se disponibili). Un errore Too many connections o Access denied orienter\u00e0 immediatamente la diagnosi.<\/p>\n Una corruzione delle tabelle (spesso dopo un crash, un disco saturo, un\u2019interruzione, o un problema hardware) pu\u00f2 provocare errori di connessione o comportamenti simili. WordPress propone una modalit\u00e0 di riparazione, e MySQL propone anche strumenti (a seconda dell\u2019accesso).<\/p>\n WordPress pu\u00f2 avviare una riparazione delle tabelle se si attiva un parametro specifico in wp-config.php<\/em>. Questo pu\u00f2 risolvere tabelle contrassegnate come crashed . Importante: disattivate questa opzione non appena la riparazione \u00e8 terminata.<\/p>\n In phpMyAdmin, potete selezionare tutte le tabelle e avviare Ripara la tabella . Se pi\u00f9 tabelle sono danneggiate, questo pu\u00f2 essere sufficiente per rimettere il sito online.<\/p>\n Per un approccio pi\u00f9 ampio (e scenari avanzati), questa guida \u00e8 utile: Correggere Errore di connessione al database ?<\/a> Esplora le cause comuni, i controlli lato server e le piste quando le soluzioni semplici non bastano.<\/p>\n Un plugin o un tema pu\u00f2 scatenare una tempesta di query, aprire troppe connessioni o provocare errori fatali che sembrano un problema DB (ad esempio, timeout ripetuti che finiscono per far cadere MySQL su un piccolo server). Anche se il messaggio parla di database, la causa iniziale pu\u00f2 essere applicativa.<\/p>\n Se avete un ambiente di staging, riproducete il problema e disattivate gli elementi uno a uno. In produzione, fatelo solo se siete sicuri di poter tornare indietro rapidamente (backup, accesso FTP\/SSH, ecc.).<\/p>\n Per un approccio prudente prima di aggiungere o modificare estensioni, potete basarvi su un protocollo di test prima della messa in produzione<\/a>, per ridurre drasticamente gli incidenti che finiscono per impattare il database.<\/p>\n I plugin obsoleti o abbandonati possono generare query inefficienti, errori SQL o incompatibilit\u00e0 con una versione recente di PHP\/MySQL. Col tempo, questo indebolisce l\u2019insieme, soprattutto se il vostro server ha risorse limitate.<\/p>\n Se dovete fare pulizia, seguite una procedura controllata: backup, disattivazione, verifica delle dipendenze, rimozione, poi osservazione. A questo proposito, ecco una risorsa interna utile: un metodo per rimuovere correttamente estensioni vecchie<\/a>.<\/p>\n Dopo una migrazione o un ripristino, pu\u00f2 capitare che il prefisso delle tabelle non corrisponda pi\u00f9 a quello dichiarato in wp-config.php<\/em>. WordPress cerca quindi tabelle che non esistono, il che pu\u00f2 essere interpretato come un problema del database (o portare a errori correlati).<\/p>\n In wp-config.php<\/em>, la variabile $table_prefix<\/em> deve corrispondere esattamente alle tabelle presenti (ad esempio wp_<\/em>, wp123_<\/em>, ecc.). Verificate in phpMyAdmin: se le vostre tabelle iniziano con wpabc_<\/em> ma il file indica wp_<\/em>, correggete uno dei due (in genere si corregge il file, salvo strategia specifica).<\/p>\n A volte il database \u00e8 stato eliminato (errore umano), rinominato o ripristinato con un altro nome. Altre volte, l\u2019utente MySQL esiste, ma non ha i privilegi sul database (GRANT mancante, utente ricreato, diritti reimpostati dall\u2019host, ecc.).<\/p>\n Scoprite le nostre offerte di manutenzione WP<\/a><\/p>\n<\/div>\n In phpMyAdmin o nel pannello dell\u2019host, controllate:<\/p>\n \u2013 che il database elencato corrisponda a DB_NAME<\/em> ; Se l\u2019errore si verifica una volta e poi scompare, \u00e8 plausibile una manutenzione o un riavvio del DB lato hosting. Al contrario, se torna (soprattutto durante i picchi di traffico), bisogna affrontare la causa strutturale: server sottodimensionato, query pesanti, assenza di cache, cron che impazzisce, ricerca interna costosa, o estensione troppo esigente.<\/p>\n Un piano d\u2019azione pragmatico:<\/p>\n \u2013 Implementare una strategia di cache adeguata (page cache, object cache a seconda del contesto). Per evitare di correggere alla cieca, potete anche analizzare le cause ricorrenti di lentezza che finiscono per mandare in crash MySQL sulle configurazioni piccole: Gli Errori di Performance pi\u00f9 Frequenti<\/a>.<\/p>\n Un database inaccessibile pu\u00f2 anche essere la conseguenza di un incidente di sicurezza: password del DB modificata, file alterati, creazione di backdoor, o query malevole che saturano il server. Non \u00e8 lo scenario pi\u00f9 comune, ma diventa probabile se osservate anche: reindirizzamenti sconosciuti, nuovi account admin, file modificati di recente, o avvisi dell\u2019host.<\/p>\n In caso di dubbio, adottate un approccio da incidente: cambio delle password (FTP\/SSH, database, WordPress), verifica dell\u2019integrit\u00e0 dei file, scan, audit degli account, ispezione dei log. Una checklist strutturata aiuta a non dimenticare nulla: Audit di Sicurezza Cosa Verificare Assolutamente<\/a>.<\/p>\n Se avete verificato wp-config.php<\/em>, testato l\u2019accesso MySQL e controllato i permessi senza risultato, \u00e8 il momento di coinvolgere l\u2019host o un team tecnico. L\u2019host potr\u00e0 confermare: guasto MySQL, limite di connessioni, incidente disco, ripristino necessario, o cambio di endpoint.<\/p>\n In aggiunta, la comunit\u00e0 WordPress francofona pu\u00f2 aiutare a interpretare i sintomi e proporre piste in base al vostro contesto: Problema \u00ab errore durante la connessione al database \u00bb<\/a>.<\/p>\n Riparare \u00e8 una cosa, evitare che torni \u00e8 un\u2019altra. Le migliori protezioni contro questo tipo di guasto sono generalmente poco glamour, ma molto efficaci: backup automatici testati, aggiornamenti regolari, monitoraggio dell\u2019uptime e controllo delle risorse (CPU\/RAM\/IO) per anticipare la saturazione.<\/p>\n \u00c8 anche utile mettere in atto delle routine: verificare lo stato del database, pulire le tabelle lasciate dai plugin, monitorare i log degli errori e mantenere una tracciabilit\u00e0 delle modifiche (chi ha fatto cosa, quando).<\/p>\n Per arbitrarsi tra il costo di un approccio preventivo e quello di un guasto (perdita di fatturato, SEO, fiducia), questa analisi aiuta a inquadrare la decisione: Manutenzione Costo vs Rischi<\/a>.<\/p>\n 1) Confermare l\u2019estensione: front + admin, e annotare il contesto (aggiornamento, migrazione, picco). Se il vostro sito \u00e8 critico (e-commerce, generazione di lead, media), ogni minuto di indisponibilit\u00e0 conta. In questo caso, delegare la diagnosi e la prevenzione a un team abituato a gestire questo tipo di incidente evita correzioni azzardate e riduce il tempo di ripristino.<\/p>\n Per una presa in carico ricorrente (aggiornamenti, backup, monitoraggio, correzioni), potete consultare Per saperne di pi\u00f9 sui nostri servizi di manutenzione del sito<\/a>.<\/p>\n![\"manutenzione](\"https:\/\/w-maintenance.pro\/wp-content\/uploads\/2025\/12\/uey8ati6d0.jpg\" "\\"Risolvere")
<\/p>\nPasso 2: controllare i parametri di connessione in wp-config.php<\/h2>\n
Punti di attenzione su DB_HOST (spesso sottovalutato)<\/h3>\n
Verificare senza sbagliare<\/h3>\n
Passo 3: testare la connessione MySQL al di fuori di WordPress<\/h2>\n
\n2) Via SSH : un comando del tipo mysql -h HOST -u USER -p<\/em> (se l\u2019host lo permette).
\n3) Tramite l\u2019interfaccia dell\u2019host: alcuni propongono un test di connessione o una pagina di stato MySQL.<\/p>\nPer saperne di pi\u00f9 sui nostri servizi di manutenzione di siti WordPress<\/h2>\n
Fase 4: verificare lo stato del server (guasto, sovraccarico, limiti)<\/h2>\n
\n\u2013 Il sito torna da solo dopo alcuni minuti, poi ricade.
\n\u2013 Anche altri siti sullo stesso hosting sono coinvolti.
\n\u2013 Le pagine impiegano molto tempo e poi finiscono in errore.<\/p>\nFase 5: attivare una diagnosi corretta (senza aggravare il guasto)<\/h2>\n
Fase 6: riparare un database potenzialmente corrotto<\/h2>\n
Riparazione tramite WordPress (opzione integrata)<\/h3>\n
Riparazione tramite phpMyAdmin<\/h3>\n
![\"wordpress](\"https:\/\/w-maintenance.pro\/wp-content\/uploads\/2025\/12\/oqtafyt5ktw.jpg\" "\\"Risolvere")
<\/p>\nPassaggio 7: isolare un conflitto plugin\/tema (quando il server DB sembra OK)<\/h2>\n
Testare senza rompere: metodo consigliato<\/h3>\n
Eliminare o sostituire le estensioni a rischio<\/h3>\n
Passaggio 8: verificare i prefissi delle tabelle e la coerenza dopo la migrazione<\/h2>\n
Passo 9: assicurarsi che il database esista e che l\u2019utente abbia i diritti<\/h2>\n
Per saperne di pi\u00f9 sui nostri servizi di manutenzione di siti WordPress<\/h2>\n
\n\u2013 che l\u2019utente DB_USER<\/em> sia effettivamente associato a questo database;
\n\u2013 che disponga dei diritti necessari (al minimo SELECT\/INSERT\/UPDATE\/DELETE\/CREATE\/ALTER a seconda delle operazioni di WordPress).<\/p>\nPasso 10: distinguere l\u2019incidente puntuale dal problema strutturale<\/h2>\n
\n\u2013 Ridurre le query costose (plugin di statistiche pesanti, ricerca, filtri complessi).
\n\u2013 Verificare le attivit\u00e0 pianificate (WP-Cron) e le automazioni esterne.
\n\u2013 Ottimizzare il database (pulizia revisioni, transients, tabelle dei plugin).
\n\u2013 Aumentare le risorse se necessario.<\/p>\nPassaggio 11: prendere in considerazione la sicurezza (intrusione, iniezione, account compromessi)<\/h2>\n
![\"supprt](\"https:\/\/w-maintenance.pro\/wp-content\/uploads\/2025\/12\/npxxwgq33zq.jpg\" "\\"Risolvere")
<\/p>\nPassaggio 12: quando chiedere aiuto (e a chi)<\/h2>\n
Prevenire la ricaduta: backup, aggiornamenti, monitoraggio<\/h2>\n
Piano d\u2019azione express (riepilogo)<\/h2>\n
\n2) Verificare DB_NAME\/DB_USER\/DB_PASSWORD\/DB_HOST<\/em> in wp-config.php<\/em>.
\n3) Testare la connessione MySQL tramite phpMyAdmin\/SSH, e controllare l\u2019esistenza del database.
\n4) Verificare i diritti dell\u2019utente sul database.
\n5) Controllare lo stato del server (guasto, limiti, too many connections , disco).
\n6) Valutare una riparazione delle tabelle se si sospetta corruzione.
\n7) Isolare un plugin\/tema esigente se il database \u00e8 OK ma il sito crolla sotto carico.
\n8) Rafforzare la prevenzione: backup, supervisione, ottimizzazione, sicurezza.<\/p>\nQuando esternalizzare: risparmiare tempo senza correre rischi<\/h2>\n