1 Utilizzare sempre il tipo di dati corretto<\/strong><\/h2>\nUna delle migliori pratiche MySQL pi\u00f9 importanti consiste nell’utilizzare i tipi di dati in base alla natura dei dati. L’utilizzo di tipi di dati irrilevanti pu\u00f2 consumare pi\u00f9 spazio o causare errori.<\/p>\n
Ad esempio: l’utilizzo di varchar (20) invece del tipo di dati DATETIME per la memorizzazione dei valori di data e ora comporter\u00e0 errori nei calcoli relativi alla data e all’ora. Inoltre, \u00e8 possibile che vengano memorizzati dati non validi.<\/p>\n
2 Utilizzare CHAR (1) su VARCHAR (1)<\/strong><\/h2>\nVARCHAR (1) richiede byte extra per memorizzare le informazioni, quindi se si esegue una stringa di un singolo carattere, \u00e8 meglio usare CHAR (1).<\/p>\n
3 Utilizzare il tipo di dati CHAR per memorizzare solo dati di lunghezza fissa<\/strong><\/h2>\nAd esempio: se la lunghezza dei dati \u00e8 inferiore a 1000, l’utilizzo di char (1000) anzich\u00e9 varchar (1000) consumer\u00e0 pi\u00f9 spazio.<\/p>\n
4 Evitare di utilizzare formati di data regionali<\/strong><\/h2>\nQuando si utilizza il tipo di dati DATETIME o DATE, utilizzare sempre il formato data AAAA-MM-GG o il formato data ISO adatto al proprio motore SQL. I formati regionali come GG-MM-AAAA o MM-GG-AAAA non verranno archiviati correttamente.<\/p>\n
5 Colonne chiave dell’indice<\/strong><\/h2>\n\u00c8 auspicabile che la query restituisca il risultato velocemente, quindi assicurati di indicizzare le colonne utilizzate nelle clausole JOIN.<\/p>\n
Nel caso in cui utilizzi l’istruzione UPDATE che coinvolge pi\u00f9 di una tabella, assicurati di indicizzare tutte le colonne utilizzate per unire le tabelle.<\/p>\n
6 Non utilizzare funzioni su colonne indicizzate…<\/strong><\/h2>\n\u2026 perch\u00e9 poi l’indice perde il suo scopo.<\/p>\n
Ad esempio, supponiamo di voler ottenere dati in cui i primi due caratteri del codice cliente sono AK. Scrivere:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne non scrivere<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nCome mai? Il primo esempio utilizzer\u00e0 l’indice, che risulter\u00e0 in un tempo di risposta pi\u00f9 rapido.<\/p>\n
7 Utilizzare SQL SELECT * solo se necessario<\/strong><\/h2>\nSeguendo l’elenco delle migliori pratiche MySQL, non utilizzare alla cieca SELECT * nel codice. Se la tabella ha molte colonne, verranno restituite tutte. Ci\u00f2 rallenter\u00e0 il tempo di risposta, soprattutto se invii il risultato a un’applicazione front-end.<\/p>\n
Invece, digita in modo esplicito i nomi delle colonne che sono effettivamente necessari.<\/p>\n
Nota: ricorda che tutte le istruzioni SELECT richiedono una clausola WHERE.<\/p>\n
8 Utilizzare la clausola ORDER BY solo se necessario<\/strong><\/h2>\nSe vuoi mostrare il risultato nell’applicazione front-end, lascia che ORDINA il set di risultati. Se si esegue questa operazione in SQL, il tempo di risposta potrebbe essere rallentato nell’ambiente multiutente.<\/p>\n
9 Scegli un Motore di database appropriato<\/strong><\/h2>\nSe sviluppi un’applicazione che legge i dati pi\u00f9 spesso della scrittura (ad esempio un motore di ricerca), scegli il motore di archiviazione MyISAM.<\/p>\n
La scelta del motore di archiviazione sbagliato influir\u00e0 sulle prestazioni.<\/p>\n
10 Utilizzare la clausola EXISTS dove necessario<\/strong><\/h2>\nPer verificare l’esistenza dei dati, utilizzare la clausola EXISTS che \u00e8 pi\u00f9 veloce nei tempi di risposta. Ad esempio, utilizzare:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNon usare :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 SPIEGARE le vostre query SELECT<\/strong><\/h2>\nSe utilizzi la parola chiave EXPLAIN, puoi ottenere informazioni dettagliate su ci\u00f2 che MySQL sta facendo per eseguire la tua query. Questo pu\u00f2 aiutarti a rilevare problemi con la tua query o con le strutture delle tabelle (ad es. colli di bottiglia).<\/p>\n
Una query EXPLAIN mostra quali indici vengono utilizzati, come la tabella viene scansionata, ordinata, ecc.<\/p>\n
Tutto quello che devi fare \u00e8 aggiungere la parola chiave EXPLAIN davanti a una query SELECT (preferibilmente complessa con join). Inoltre, se usi phpmyadmin per questo, i tuoi risultati verranno mostrati in una bella tabella.<\/p>\n
12 Utilizzare LIMIT 1 quando si ottiene una riga univoca<\/strong><\/h2>\nA volte sai in anticipo che stai cercando solo una riga quando esegui query sulle tue tabelle. Ad esempio, potresti recuperare un record univoco o semplicemente verificare l’esistenza di un numero qualsiasi di record che soddisfano la tua clausola WHERE.<\/p>\n
In questi casi, ti consigliamo di utilizzare la funzione limite di MySQL per aumentare le prestazioni. Ecco un’altra delle migliori pratiche MySQL: aggiungi semplicemente LIMIT 1 alla tua query. In questo modo il motore di database non dovr\u00e0 passare attraverso l’intera tabella o indice. Interromper\u00e0 la scansione quando trova solo 1 record di ci\u00f2 che stai cercando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ cosa NON fare:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ molto meglio:
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indicizzare e utilizzare gli stessi tipi di colonna per i join<\/strong><\/h2>\nUn altro suggerimento fondamentale per le migliori pratiche MySQL: se la tua applicazione ha molte query JOIN, assicurati che le colonne in base alle quali ti unisci siano indicizzate su entrambe le tabelle. Ci\u00f2 influisce sull’ottimizzazione interna dell’operazione di join da parte di MySQL.<\/p>\n
Inoltre, le colonne unite devono essere dello stesso tipo. Ad esempio, se unisci una colonna DECIMAL a una colonna INT da un’altra tabella, MySQL non sar\u00e0 in grado di utilizzare nessuno degli indici. Anche le codifiche dei caratteri devono essere dello stesso tipo per le colonne di tipo stringa.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ entrambe le colonne di stato dovrebbero essere indicizzate
\n\/\/ ed entrambe dovrebbero essere dello stesso tipo e codifica dei caratteri
\n\/\/ o MySQL potrebbe eseguire scansioni complete della tabella<\/p>\n
14 Nascondere MySQL da Internet<\/strong><\/h2>\nAmministratori di database esperti e personale di sicurezza lo sanno: non ospitare mai il database nella radice del server Web.<\/p>\n
Per le applicazioni abilitate al Web, MySQL dovrebbe essere nascosto dietro un firewall. La comunicazione deve essere abilitata solo tra i server delle applicazioni ei server Web.<\/p>\n
Un’altra opzione consiste nell’utilizzare la rete di salto MySQL. Quando \u00e8 abilitato, MySQL ascolta solo le connessioni socket locali e ignora tutte le porte TCP.<\/p>\n
15 Utilizzare i tipi di dati pi\u00f9 piccoli possibili<\/strong><\/h2>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b73d55e.jpg\")
<\/a><\/p>\nLascia che ti racconti una storia. Quando frequentavo il college, la filosofia era che "la memoria \u00e8 scarsa". Erano i giorni dei dischi rigidi da 256 MB. Al giorno d’oggi, a nessuno sembra importare un briciolo di memoria o spazio sul disco rigido. La nuova filosofia \u00e8 che "la memoria costa poco". Potrebbe essere vero in termini di dollari, ma la lettura di tipi di dati di grandi dimensioni richiede ancora pi\u00f9 tempo rispetto alla lettura di tipi di dati pi\u00f9 piccoli. I tipi di dati di grandi dimensioni richiedono la lettura in memoria di pi\u00f9 settori del disco.<\/p>\n
La morale \u00e8 ignorare la tentazione di passare immediatamente al tipo di dati pi\u00f9 grande quando si progettano le tabelle. Pensa di usare un int invece di un bigint.<\/p>\n
Inoltre, evita i campi di testo largechar (255) quando \u00e8 sufficiente un varchar o un char pi\u00f9 piccolo.<\/p>\n
Se si utilizza il tipo di dati corretto, pi\u00f9 record si adatteranno alla memoria o al blocco chiave dell’indice. Ci\u00f2 porta a un minor numero di letture e prestazioni pi\u00f9 veloci.<\/p>\n
16 Approfitta della memorizzazione nella cache delle query<\/strong><\/h2>\nLa memorizzazione nella cache delle query \u00e8 uno dei metodi pi\u00f9 efficaci per migliorare le prestazioni. La maggior parte dei server MySQL lo ha abilitato per impostazione predefinita.<\/p>\n
La cache delle query memorizza il testo di un’istruzione SELECT insieme al set di risultati corrispondente. Se in seguito il server riceve un’istruzione identica, recuperer\u00e0 i risultati dalla cache delle query anzich\u00e9 analizzare ed eseguire nuovamente l’istruzione. La cache delle query \u00e8 condivisa tra le sessioni, quindi un set di risultati generato da un client pu\u00f2 essere inviato in risposta alla stessa query emessa da un altro client.<\/p>\n
Tuttavia, per quanto grande sia, la memorizzazione nella cache delle query ha i suoi limiti. Prendi la seguente affermazione:<\/p>\n
Il problema qui \u00e8 che le query contengono alcune funzioni non deterministiche, come NOW() e RAND(). MySQL non \u00e8 in grado di calcolare tali funzioni in anticipo, quindi finiscono per non essere memorizzate nella cache.<\/p>\n
Fortunatamente, esiste una soluzione semplice: \u00e8 possibile memorizzare i risultati della funzione in una variabile.<\/p>\n
17 Non modificare i file di dump<\/strong><\/h2>\nI file di dump sono molto ingannevoli e possono causare danni. Come mai? Se hai mai visto i file di dump creati da mysqldump, sarai d’accordo sul fatto che assomiglino a normali file di testo innocui. Questo \u00e8 il motivo per cui la maggior parte delle persone li modifica in un editor di testo standard, che fa apparire i danneggiamenti.<\/p>\n
Se hai mai provato a modificare i file di dump, hai subito imparato che sono tutt’altro che un file di testo. Quindi, l’unico modo garantito per evitare problemi \u00e8 lasciare i file dump da soli.<\/p>\n
18 Utilizzare l’impostazione della dimensione del blocco MyISAM<\/strong><\/h2>\n
VARCHAR (1) richiede byte extra per memorizzare le informazioni, quindi se si esegue una stringa di un singolo carattere, \u00e8 meglio usare CHAR (1).<\/p>\n
3 Utilizzare il tipo di dati CHAR per memorizzare solo dati di lunghezza fissa<\/strong><\/h2>\nAd esempio: se la lunghezza dei dati \u00e8 inferiore a 1000, l’utilizzo di char (1000) anzich\u00e9 varchar (1000) consumer\u00e0 pi\u00f9 spazio.<\/p>\n
4 Evitare di utilizzare formati di data regionali<\/strong><\/h2>\nQuando si utilizza il tipo di dati DATETIME o DATE, utilizzare sempre il formato data AAAA-MM-GG o il formato data ISO adatto al proprio motore SQL. I formati regionali come GG-MM-AAAA o MM-GG-AAAA non verranno archiviati correttamente.<\/p>\n
5 Colonne chiave dell’indice<\/strong><\/h2>\n\u00c8 auspicabile che la query restituisca il risultato velocemente, quindi assicurati di indicizzare le colonne utilizzate nelle clausole JOIN.<\/p>\n
Nel caso in cui utilizzi l’istruzione UPDATE che coinvolge pi\u00f9 di una tabella, assicurati di indicizzare tutte le colonne utilizzate per unire le tabelle.<\/p>\n
6 Non utilizzare funzioni su colonne indicizzate…<\/strong><\/h2>\n\u2026 perch\u00e9 poi l’indice perde il suo scopo.<\/p>\n
Ad esempio, supponiamo di voler ottenere dati in cui i primi due caratteri del codice cliente sono AK. Scrivere:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne non scrivere<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nCome mai? Il primo esempio utilizzer\u00e0 l’indice, che risulter\u00e0 in un tempo di risposta pi\u00f9 rapido.<\/p>\n
7 Utilizzare SQL SELECT * solo se necessario<\/strong><\/h2>\nSeguendo l’elenco delle migliori pratiche MySQL, non utilizzare alla cieca SELECT * nel codice. Se la tabella ha molte colonne, verranno restituite tutte. Ci\u00f2 rallenter\u00e0 il tempo di risposta, soprattutto se invii il risultato a un’applicazione front-end.<\/p>\n
Invece, digita in modo esplicito i nomi delle colonne che sono effettivamente necessari.<\/p>\n
Nota: ricorda che tutte le istruzioni SELECT richiedono una clausola WHERE.<\/p>\n
8 Utilizzare la clausola ORDER BY solo se necessario<\/strong><\/h2>\nSe vuoi mostrare il risultato nell’applicazione front-end, lascia che ORDINA il set di risultati. Se si esegue questa operazione in SQL, il tempo di risposta potrebbe essere rallentato nell’ambiente multiutente.<\/p>\n
9 Scegli un Motore di database appropriato<\/strong><\/h2>\nSe sviluppi un’applicazione che legge i dati pi\u00f9 spesso della scrittura (ad esempio un motore di ricerca), scegli il motore di archiviazione MyISAM.<\/p>\n
La scelta del motore di archiviazione sbagliato influir\u00e0 sulle prestazioni.<\/p>\n
10 Utilizzare la clausola EXISTS dove necessario<\/strong><\/h2>\nPer verificare l’esistenza dei dati, utilizzare la clausola EXISTS che \u00e8 pi\u00f9 veloce nei tempi di risposta. Ad esempio, utilizzare:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNon usare :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 SPIEGARE le vostre query SELECT<\/strong><\/h2>\nSe utilizzi la parola chiave EXPLAIN, puoi ottenere informazioni dettagliate su ci\u00f2 che MySQL sta facendo per eseguire la tua query. Questo pu\u00f2 aiutarti a rilevare problemi con la tua query o con le strutture delle tabelle (ad es. colli di bottiglia).<\/p>\n
Una query EXPLAIN mostra quali indici vengono utilizzati, come la tabella viene scansionata, ordinata, ecc.<\/p>\n
Tutto quello che devi fare \u00e8 aggiungere la parola chiave EXPLAIN davanti a una query SELECT (preferibilmente complessa con join). Inoltre, se usi phpmyadmin per questo, i tuoi risultati verranno mostrati in una bella tabella.<\/p>\n
12 Utilizzare LIMIT 1 quando si ottiene una riga univoca<\/strong><\/h2>\nA volte sai in anticipo che stai cercando solo una riga quando esegui query sulle tue tabelle. Ad esempio, potresti recuperare un record univoco o semplicemente verificare l’esistenza di un numero qualsiasi di record che soddisfano la tua clausola WHERE.<\/p>\n
In questi casi, ti consigliamo di utilizzare la funzione limite di MySQL per aumentare le prestazioni. Ecco un’altra delle migliori pratiche MySQL: aggiungi semplicemente LIMIT 1 alla tua query. In questo modo il motore di database non dovr\u00e0 passare attraverso l’intera tabella o indice. Interromper\u00e0 la scansione quando trova solo 1 record di ci\u00f2 che stai cercando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ cosa NON fare:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ molto meglio:
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indicizzare e utilizzare gli stessi tipi di colonna per i join<\/strong><\/h2>\nUn altro suggerimento fondamentale per le migliori pratiche MySQL: se la tua applicazione ha molte query JOIN, assicurati che le colonne in base alle quali ti unisci siano indicizzate su entrambe le tabelle. Ci\u00f2 influisce sull’ottimizzazione interna dell’operazione di join da parte di MySQL.<\/p>\n
Inoltre, le colonne unite devono essere dello stesso tipo. Ad esempio, se unisci una colonna DECIMAL a una colonna INT da un’altra tabella, MySQL non sar\u00e0 in grado di utilizzare nessuno degli indici. Anche le codifiche dei caratteri devono essere dello stesso tipo per le colonne di tipo stringa.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ entrambe le colonne di stato dovrebbero essere indicizzate
\n\/\/ ed entrambe dovrebbero essere dello stesso tipo e codifica dei caratteri
\n\/\/ o MySQL potrebbe eseguire scansioni complete della tabella<\/p>\n
14 Nascondere MySQL da Internet<\/strong><\/h2>\nAmministratori di database esperti e personale di sicurezza lo sanno: non ospitare mai il database nella radice del server Web.<\/p>\n
Per le applicazioni abilitate al Web, MySQL dovrebbe essere nascosto dietro un firewall. La comunicazione deve essere abilitata solo tra i server delle applicazioni ei server Web.<\/p>\n
Un’altra opzione consiste nell’utilizzare la rete di salto MySQL. Quando \u00e8 abilitato, MySQL ascolta solo le connessioni socket locali e ignora tutte le porte TCP.<\/p>\n
15 Utilizzare i tipi di dati pi\u00f9 piccoli possibili<\/strong><\/h2>\n<\/a><\/p>\nLascia che ti racconti una storia. Quando frequentavo il college, la filosofia era che "la memoria \u00e8 scarsa". Erano i giorni dei dischi rigidi da 256 MB. Al giorno d’oggi, a nessuno sembra importare un briciolo di memoria o spazio sul disco rigido. La nuova filosofia \u00e8 che "la memoria costa poco". Potrebbe essere vero in termini di dollari, ma la lettura di tipi di dati di grandi dimensioni richiede ancora pi\u00f9 tempo rispetto alla lettura di tipi di dati pi\u00f9 piccoli. I tipi di dati di grandi dimensioni richiedono la lettura in memoria di pi\u00f9 settori del disco.<\/p>\n
La morale \u00e8 ignorare la tentazione di passare immediatamente al tipo di dati pi\u00f9 grande quando si progettano le tabelle. Pensa di usare un int invece di un bigint.<\/p>\n
Inoltre, evita i campi di testo largechar (255) quando \u00e8 sufficiente un varchar o un char pi\u00f9 piccolo.<\/p>\n
Se si utilizza il tipo di dati corretto, pi\u00f9 record si adatteranno alla memoria o al blocco chiave dell’indice. Ci\u00f2 porta a un minor numero di letture e prestazioni pi\u00f9 veloci.<\/p>\n
16 Approfitta della memorizzazione nella cache delle query<\/strong><\/h2>\nLa memorizzazione nella cache delle query \u00e8 uno dei metodi pi\u00f9 efficaci per migliorare le prestazioni. La maggior parte dei server MySQL lo ha abilitato per impostazione predefinita.<\/p>\n
La cache delle query memorizza il testo di un’istruzione SELECT insieme al set di risultati corrispondente. Se in seguito il server riceve un’istruzione identica, recuperer\u00e0 i risultati dalla cache delle query anzich\u00e9 analizzare ed eseguire nuovamente l’istruzione. La cache delle query \u00e8 condivisa tra le sessioni, quindi un set di risultati generato da un client pu\u00f2 essere inviato in risposta alla stessa query emessa da un altro client.<\/p>\n
Tuttavia, per quanto grande sia, la memorizzazione nella cache delle query ha i suoi limiti. Prendi la seguente affermazione:<\/p>\n
Il problema qui \u00e8 che le query contengono alcune funzioni non deterministiche, come NOW() e RAND(). MySQL non \u00e8 in grado di calcolare tali funzioni in anticipo, quindi finiscono per non essere memorizzate nella cache.<\/p>\n
Fortunatamente, esiste una soluzione semplice: \u00e8 possibile memorizzare i risultati della funzione in una variabile.<\/p>\n
17 Non modificare i file di dump<\/strong><\/h2>\nI file di dump sono molto ingannevoli e possono causare danni. Come mai? Se hai mai visto i file di dump creati da mysqldump, sarai d’accordo sul fatto che assomiglino a normali file di testo innocui. Questo \u00e8 il motivo per cui la maggior parte delle persone li modifica in un editor di testo standard, che fa apparire i danneggiamenti.<\/p>\n
Se hai mai provato a modificare i file di dump, hai subito imparato che sono tutt’altro che un file di testo. Quindi, l’unico modo garantito per evitare problemi \u00e8 lasciare i file dump da soli.<\/p>\n
18 Utilizzare l’impostazione della dimensione del blocco MyISAM<\/strong><\/h2>\n
Quando si utilizza il tipo di dati DATETIME o DATE, utilizzare sempre il formato data AAAA-MM-GG o il formato data ISO adatto al proprio motore SQL. I formati regionali come GG-MM-AAAA o MM-GG-AAAA non verranno archiviati correttamente.<\/p>\n
5 Colonne chiave dell’indice<\/strong><\/h2>\n\u00c8 auspicabile che la query restituisca il risultato velocemente, quindi assicurati di indicizzare le colonne utilizzate nelle clausole JOIN.<\/p>\n
Nel caso in cui utilizzi l’istruzione UPDATE che coinvolge pi\u00f9 di una tabella, assicurati di indicizzare tutte le colonne utilizzate per unire le tabelle.<\/p>\n
6 Non utilizzare funzioni su colonne indicizzate…<\/strong><\/h2>\n\u2026 perch\u00e9 poi l’indice perde il suo scopo.<\/p>\n
Ad esempio, supponiamo di voler ottenere dati in cui i primi due caratteri del codice cliente sono AK. Scrivere:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne non scrivere<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nCome mai? Il primo esempio utilizzer\u00e0 l’indice, che risulter\u00e0 in un tempo di risposta pi\u00f9 rapido.<\/p>\n
7 Utilizzare SQL SELECT * solo se necessario<\/strong><\/h2>\nSeguendo l’elenco delle migliori pratiche MySQL, non utilizzare alla cieca SELECT * nel codice. Se la tabella ha molte colonne, verranno restituite tutte. Ci\u00f2 rallenter\u00e0 il tempo di risposta, soprattutto se invii il risultato a un’applicazione front-end.<\/p>\n
Invece, digita in modo esplicito i nomi delle colonne che sono effettivamente necessari.<\/p>\n
Nota: ricorda che tutte le istruzioni SELECT richiedono una clausola WHERE.<\/p>\n
8 Utilizzare la clausola ORDER BY solo se necessario<\/strong><\/h2>\nSe vuoi mostrare il risultato nell’applicazione front-end, lascia che ORDINA il set di risultati. Se si esegue questa operazione in SQL, il tempo di risposta potrebbe essere rallentato nell’ambiente multiutente.<\/p>\n
9 Scegli un Motore di database appropriato<\/strong><\/h2>\nSe sviluppi un’applicazione che legge i dati pi\u00f9 spesso della scrittura (ad esempio un motore di ricerca), scegli il motore di archiviazione MyISAM.<\/p>\n
La scelta del motore di archiviazione sbagliato influir\u00e0 sulle prestazioni.<\/p>\n
10 Utilizzare la clausola EXISTS dove necessario<\/strong><\/h2>\nPer verificare l’esistenza dei dati, utilizzare la clausola EXISTS che \u00e8 pi\u00f9 veloce nei tempi di risposta. Ad esempio, utilizzare:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNon usare :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 SPIEGARE le vostre query SELECT<\/strong><\/h2>\nSe utilizzi la parola chiave EXPLAIN, puoi ottenere informazioni dettagliate su ci\u00f2 che MySQL sta facendo per eseguire la tua query. Questo pu\u00f2 aiutarti a rilevare problemi con la tua query o con le strutture delle tabelle (ad es. colli di bottiglia).<\/p>\n
Una query EXPLAIN mostra quali indici vengono utilizzati, come la tabella viene scansionata, ordinata, ecc.<\/p>\n
Tutto quello che devi fare \u00e8 aggiungere la parola chiave EXPLAIN davanti a una query SELECT (preferibilmente complessa con join). Inoltre, se usi phpmyadmin per questo, i tuoi risultati verranno mostrati in una bella tabella.<\/p>\n
12 Utilizzare LIMIT 1 quando si ottiene una riga univoca<\/strong><\/h2>\nA volte sai in anticipo che stai cercando solo una riga quando esegui query sulle tue tabelle. Ad esempio, potresti recuperare un record univoco o semplicemente verificare l’esistenza di un numero qualsiasi di record che soddisfano la tua clausola WHERE.<\/p>\n
In questi casi, ti consigliamo di utilizzare la funzione limite di MySQL per aumentare le prestazioni. Ecco un’altra delle migliori pratiche MySQL: aggiungi semplicemente LIMIT 1 alla tua query. In questo modo il motore di database non dovr\u00e0 passare attraverso l’intera tabella o indice. Interromper\u00e0 la scansione quando trova solo 1 record di ci\u00f2 che stai cercando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ cosa NON fare:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ molto meglio:
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indicizzare e utilizzare gli stessi tipi di colonna per i join<\/strong><\/h2>\nUn altro suggerimento fondamentale per le migliori pratiche MySQL: se la tua applicazione ha molte query JOIN, assicurati che le colonne in base alle quali ti unisci siano indicizzate su entrambe le tabelle. Ci\u00f2 influisce sull’ottimizzazione interna dell’operazione di join da parte di MySQL.<\/p>\n
Inoltre, le colonne unite devono essere dello stesso tipo. Ad esempio, se unisci una colonna DECIMAL a una colonna INT da un’altra tabella, MySQL non sar\u00e0 in grado di utilizzare nessuno degli indici. Anche le codifiche dei caratteri devono essere dello stesso tipo per le colonne di tipo stringa.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ entrambe le colonne di stato dovrebbero essere indicizzate
\n\/\/ ed entrambe dovrebbero essere dello stesso tipo e codifica dei caratteri
\n\/\/ o MySQL potrebbe eseguire scansioni complete della tabella<\/p>\n
14 Nascondere MySQL da Internet<\/strong><\/h2>\nAmministratori di database esperti e personale di sicurezza lo sanno: non ospitare mai il database nella radice del server Web.<\/p>\n
Per le applicazioni abilitate al Web, MySQL dovrebbe essere nascosto dietro un firewall. La comunicazione deve essere abilitata solo tra i server delle applicazioni ei server Web.<\/p>\n
Un’altra opzione consiste nell’utilizzare la rete di salto MySQL. Quando \u00e8 abilitato, MySQL ascolta solo le connessioni socket locali e ignora tutte le porte TCP.<\/p>\n
15 Utilizzare i tipi di dati pi\u00f9 piccoli possibili<\/strong><\/h2>\n<\/a><\/p>\nLascia che ti racconti una storia. Quando frequentavo il college, la filosofia era che "la memoria \u00e8 scarsa". Erano i giorni dei dischi rigidi da 256 MB. Al giorno d’oggi, a nessuno sembra importare un briciolo di memoria o spazio sul disco rigido. La nuova filosofia \u00e8 che "la memoria costa poco". Potrebbe essere vero in termini di dollari, ma la lettura di tipi di dati di grandi dimensioni richiede ancora pi\u00f9 tempo rispetto alla lettura di tipi di dati pi\u00f9 piccoli. I tipi di dati di grandi dimensioni richiedono la lettura in memoria di pi\u00f9 settori del disco.<\/p>\n
La morale \u00e8 ignorare la tentazione di passare immediatamente al tipo di dati pi\u00f9 grande quando si progettano le tabelle. Pensa di usare un int invece di un bigint.<\/p>\n
Inoltre, evita i campi di testo largechar (255) quando \u00e8 sufficiente un varchar o un char pi\u00f9 piccolo.<\/p>\n
Se si utilizza il tipo di dati corretto, pi\u00f9 record si adatteranno alla memoria o al blocco chiave dell’indice. Ci\u00f2 porta a un minor numero di letture e prestazioni pi\u00f9 veloci.<\/p>\n
16 Approfitta della memorizzazione nella cache delle query<\/strong><\/h2>\nLa memorizzazione nella cache delle query \u00e8 uno dei metodi pi\u00f9 efficaci per migliorare le prestazioni. La maggior parte dei server MySQL lo ha abilitato per impostazione predefinita.<\/p>\n
La cache delle query memorizza il testo di un’istruzione SELECT insieme al set di risultati corrispondente. Se in seguito il server riceve un’istruzione identica, recuperer\u00e0 i risultati dalla cache delle query anzich\u00e9 analizzare ed eseguire nuovamente l’istruzione. La cache delle query \u00e8 condivisa tra le sessioni, quindi un set di risultati generato da un client pu\u00f2 essere inviato in risposta alla stessa query emessa da un altro client.<\/p>\n
Tuttavia, per quanto grande sia, la memorizzazione nella cache delle query ha i suoi limiti. Prendi la seguente affermazione:<\/p>\n
Il problema qui \u00e8 che le query contengono alcune funzioni non deterministiche, come NOW() e RAND(). MySQL non \u00e8 in grado di calcolare tali funzioni in anticipo, quindi finiscono per non essere memorizzate nella cache.<\/p>\n
Fortunatamente, esiste una soluzione semplice: \u00e8 possibile memorizzare i risultati della funzione in una variabile.<\/p>\n
17 Non modificare i file di dump<\/strong><\/h2>\nI file di dump sono molto ingannevoli e possono causare danni. Come mai? Se hai mai visto i file di dump creati da mysqldump, sarai d’accordo sul fatto che assomiglino a normali file di testo innocui. Questo \u00e8 il motivo per cui la maggior parte delle persone li modifica in un editor di testo standard, che fa apparire i danneggiamenti.<\/p>\n
Se hai mai provato a modificare i file di dump, hai subito imparato che sono tutt’altro che un file di testo. Quindi, l’unico modo garantito per evitare problemi \u00e8 lasciare i file dump da soli.<\/p>\n
18 Utilizzare l’impostazione della dimensione del blocco MyISAM<\/strong><\/h2>\n
\u2026 perch\u00e9 poi l’indice perde il suo scopo.<\/p>\n
Ad esempio, supponiamo di voler ottenere dati in cui i primi due caratteri del codice cliente sono AK. Scrivere:<\/p>\n
e non scrivere<\/p>\n Come mai? Il primo esempio utilizzer\u00e0 l’indice, che risulter\u00e0 in un tempo di risposta pi\u00f9 rapido.<\/p>\n Seguendo l’elenco delle migliori pratiche MySQL, non utilizzare alla cieca SELECT * nel codice. Se la tabella ha molte colonne, verranno restituite tutte. Ci\u00f2 rallenter\u00e0 il tempo di risposta, soprattutto se invii il risultato a un’applicazione front-end.<\/p>\n Invece, digita in modo esplicito i nomi delle colonne che sono effettivamente necessari.<\/p>\n Nota: ricorda che tutte le istruzioni SELECT richiedono una clausola WHERE.<\/p>\n Se vuoi mostrare il risultato nell’applicazione front-end, lascia che ORDINA il set di risultati. Se si esegue questa operazione in SQL, il tempo di risposta potrebbe essere rallentato nell’ambiente multiutente.<\/p>\n Se sviluppi un’applicazione che legge i dati pi\u00f9 spesso della scrittura (ad esempio un motore di ricerca), scegli il motore di archiviazione MyISAM.<\/p>\n La scelta del motore di archiviazione sbagliato influir\u00e0 sulle prestazioni.<\/p>\n Per verificare l’esistenza dei dati, utilizzare la clausola EXISTS che \u00e8 pi\u00f9 veloce nei tempi di risposta. Ad esempio, utilizzare:<\/p>\n Non usare :<\/p>\n Se utilizzi la parola chiave EXPLAIN, puoi ottenere informazioni dettagliate su ci\u00f2 che MySQL sta facendo per eseguire la tua query. Questo pu\u00f2 aiutarti a rilevare problemi con la tua query o con le strutture delle tabelle (ad es. colli di bottiglia).<\/p>\n Una query EXPLAIN mostra quali indici vengono utilizzati, come la tabella viene scansionata, ordinata, ecc.<\/p>\n Tutto quello che devi fare \u00e8 aggiungere la parola chiave EXPLAIN davanti a una query SELECT (preferibilmente complessa con join). Inoltre, se usi phpmyadmin per questo, i tuoi risultati verranno mostrati in una bella tabella.<\/p>\n A volte sai in anticipo che stai cercando solo una riga quando esegui query sulle tue tabelle. Ad esempio, potresti recuperare un record univoco o semplicemente verificare l’esistenza di un numero qualsiasi di record che soddisfano la tua clausola WHERE.<\/p>\n In questi casi, ti consigliamo di utilizzare la funzione limite di MySQL per aumentare le prestazioni. Ecco un’altra delle migliori pratiche MySQL: aggiungi semplicemente LIMIT 1 alla tua query. In questo modo il motore di database non dovr\u00e0 passare attraverso l’intera tabella o indice. Interromper\u00e0 la scansione quando trova solo 1 record di ci\u00f2 che stai cercando.<\/p>\n \/\/ cosa NON fare: \/\/ molto meglio: Un altro suggerimento fondamentale per le migliori pratiche MySQL: se la tua applicazione ha molte query JOIN, assicurati che le colonne in base alle quali ti unisci siano indicizzate su entrambe le tabelle. Ci\u00f2 influisce sull’ottimizzazione interna dell’operazione di join da parte di MySQL.<\/p>\n Inoltre, le colonne unite devono essere dello stesso tipo. Ad esempio, se unisci una colonna DECIMAL a una colonna INT da un’altra tabella, MySQL non sar\u00e0 in grado di utilizzare nessuno degli indici. Anche le codifiche dei caratteri devono essere dello stesso tipo per le colonne di tipo stringa.<\/p>\n \/\/ entrambe le colonne di stato dovrebbero essere indicizzate Amministratori di database esperti e personale di sicurezza lo sanno: non ospitare mai il database nella radice del server Web.<\/p>\n Per le applicazioni abilitate al Web, MySQL dovrebbe essere nascosto dietro un firewall. La comunicazione deve essere abilitata solo tra i server delle applicazioni ei server Web.<\/p>\n Un’altra opzione consiste nell’utilizzare la rete di salto MySQL. Quando \u00e8 abilitato, MySQL ascolta solo le connessioni socket locali e ignora tutte le porte TCP.<\/p>\n Lascia che ti racconti una storia. Quando frequentavo il college, la filosofia era che "la memoria \u00e8 scarsa". Erano i giorni dei dischi rigidi da 256 MB. Al giorno d’oggi, a nessuno sembra importare un briciolo di memoria o spazio sul disco rigido. La nuova filosofia \u00e8 che "la memoria costa poco". Potrebbe essere vero in termini di dollari, ma la lettura di tipi di dati di grandi dimensioni richiede ancora pi\u00f9 tempo rispetto alla lettura di tipi di dati pi\u00f9 piccoli. I tipi di dati di grandi dimensioni richiedono la lettura in memoria di pi\u00f9 settori del disco.<\/p>\n La morale \u00e8 ignorare la tentazione di passare immediatamente al tipo di dati pi\u00f9 grande quando si progettano le tabelle. Pensa di usare un int invece di un bigint.<\/p>\n Inoltre, evita i campi di testo largechar (255) quando \u00e8 sufficiente un varchar o un char pi\u00f9 piccolo.<\/p>\n Se si utilizza il tipo di dati corretto, pi\u00f9 record si adatteranno alla memoria o al blocco chiave dell’indice. Ci\u00f2 porta a un minor numero di letture e prestazioni pi\u00f9 veloci.<\/p>\n La memorizzazione nella cache delle query \u00e8 uno dei metodi pi\u00f9 efficaci per migliorare le prestazioni. La maggior parte dei server MySQL lo ha abilitato per impostazione predefinita.<\/p>\n La cache delle query memorizza il testo di un’istruzione SELECT insieme al set di risultati corrispondente. Se in seguito il server riceve un’istruzione identica, recuperer\u00e0 i risultati dalla cache delle query anzich\u00e9 analizzare ed eseguire nuovamente l’istruzione. La cache delle query \u00e8 condivisa tra le sessioni, quindi un set di risultati generato da un client pu\u00f2 essere inviato in risposta alla stessa query emessa da un altro client.<\/p>\n Tuttavia, per quanto grande sia, la memorizzazione nella cache delle query ha i suoi limiti. Prendi la seguente affermazione:<\/p>\n Il problema qui \u00e8 che le query contengono alcune funzioni non deterministiche, come NOW() e RAND(). MySQL non \u00e8 in grado di calcolare tali funzioni in anticipo, quindi finiscono per non essere memorizzate nella cache.<\/p>\n Fortunatamente, esiste una soluzione semplice: \u00e8 possibile memorizzare i risultati della funzione in una variabile.<\/p>\n I file di dump sono molto ingannevoli e possono causare danni. Come mai? Se hai mai visto i file di dump creati da mysqldump, sarai d’accordo sul fatto che assomiglino a normali file di testo innocui. Questo \u00e8 il motivo per cui la maggior parte delle persone li modifica in un editor di testo standard, che fa apparire i danneggiamenti.<\/p>\n Se hai mai provato a modificare i file di dump, hai subito imparato che sono tutt’altro che un file di testo. Quindi, l’unico modo garantito per evitare problemi \u00e8 lasciare i file dump da soli.<\/p>\nSELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\nSELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n7 Utilizzare SQL SELECT * solo se necessario<\/strong><\/h2>\n
8 Utilizzare la clausola ORDER BY solo se necessario<\/strong><\/h2>\n
9 Scegli un Motore di database appropriato<\/strong><\/h2>\n
10 Utilizzare la clausola EXISTS dove necessario<\/strong><\/h2>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nIf (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 SPIEGARE le vostre query SELECT<\/strong><\/h2>\n
12 Utilizzare LIMIT 1 quando si ottiene una riga univoca<\/strong><\/h2>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n13 Indicizzare e utilizzare gli stessi tipi di colonna per i join<\/strong><\/h2>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n
\n\/\/ ed entrambe dovrebbero essere dello stesso tipo e codifica dei caratteri
\n\/\/ o MySQL potrebbe eseguire scansioni complete della tabella<\/p>\n14 Nascondere MySQL da Internet<\/strong><\/h2>\n
15 Utilizzare i tipi di dati pi\u00f9 piccoli possibili<\/strong><\/h2>\n
<\/a><\/p>\n16 Approfitta della memorizzazione nella cache delle query<\/strong><\/h2>\n
17 Non modificare i file di dump<\/strong><\/h2>\n
18 Utilizzare l’impostazione della dimensione del blocco MyISAM<\/strong><\/h2>\n
![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b8518b8.jpg\")
<\/a><\/p>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b96bb8a.jpg\")
<\/a><\/p>\n