Mysql
 sql >> Database >  >> RDS >> Mysql

Ottimizzazione delle prestazioni delle query in MySQL

Gli esperti sanno come scrivere query efficienti in termini di prestazioni. Sebbene l'esperienza faccia maturare saggezza, ci sono alcune cose che bisogna capire almeno all'inizio. Ad esempio, è necessario comprendere le considerazioni chiave sulla progettazione delle query; come si comporta una query internamente, dove fallisce, modelli di ottimizzazione e così via. In questo articolo fornirò alcuni punti di ottimizzazione su cui riflettere durante la progettazione di una query in MySQL.

Perché alcune query sono lente?

Un problema comune con le query SQL è che vengono recuperati più dati di quelli effettivamente necessari. Naturalmente, ci sono query che setacciano molti dati e non possiamo farci molto, ma non sono comuni. Nella maggior parte dei casi è una cattiva progettazione delle query che porta a scarse prestazioni delle query. Dopo ogni progettazione di query è necessario esaminare un paio di aspetti come ciò che potrebbe accadere dopo l'attivazione della query:

  1. La query SQL accederà a troppe colonne o righe?
  2. Il server MySQL analizzerà troppe righe per recuperare il risultato desiderato?

Ci sono query che fanno in modo che il server MySQL analizzi troppi dati ma li lancia mentre li setaccia. Questo è un lavoro extra per il server in termini di molti aspetti come sovraccarico della rete, consumo eccessivo di memoria o utilizzo eccessivo delle risorse della CPU sul server. La conseguenza è una performance lenta.

Ci sono situazioni in cui potresti non essere in grado di aiutare molto durante la sua progettazione, ma c'è una situazione in cui se stai attento e stimi le conseguenze e introspezione, allora una query errata può almeno essere corretta se non migliore.

Errori tipici e loro soluzioni

Ci sono alcuni errori comuni spesso commessi durante la scrittura di una query. Eccone alcuni. Puoi trovare qualche altro pensiero sulla stessa linea. Ecco i motivi per cui le prestazioni delle query sono lente con possibili soluzioni.

Troppe righe

Spesso si commette l'errore di scrivere una query che recupera i dati e presumere che MySQL fornirà risultati su richiesta, trascurando la quantità di elaborazione richiesta per restituire l'intero set di risultati. Si supponga che un'istruzione SELECT venga attivata per recuperare i dettagli di 100 prodotti per un sito di e-commerce quando solo 10 di essi devono effettivamente essere mostrati per primi. Potresti pensare che MySQL recuperi solo 10 righe e smetta di eseguire la query. Ma no. Quello che fa MySQL è generare il set di risultati completo e alimentare il client. La libreria client riceve il set completo e ne scarta la maggior parte e ne conserva solo 10 di cui cerca. Questo chiaramente spreca molte risorse.

Tuttavia, in una situazione del genere puoi fornire una soluzione utilizzando la clausola LIMIT con la query.

SELECT
      col1, col2,...
FROM
      table_name
LIMIT
      [offset,] count; 

La clausola LIMIT accetta uno o due parametri. Il primo specifica l'offset e il secondo specifica il conteggio. Se viene specificato un solo parametro, denota il numero di righe dall'inizio del set di risultati.

Ad esempio, per selezionare 10 righe dalla tabella, puoi scrivere:

SELECT
      e.emp_name, e.phone, e.email
FROM 
      employee e
LIMIT 10;

E per selezionare le 10 righe successive, partendo da 11 record, puoi scrivere:

SELECT
      e.emp_name, e.phone, e.email
FROM
      employee e
LIMIT 10, 10;

Troppe colonne

Guarda sempre la query:SELECT * con sospetto. Questa query restituisce tutte le colonne e probabilmente sono necessarie solo alcune di esse. Il più grande svantaggio del recupero di tutte le colonne è che impedisce l'ottimizzazione ostacolando l'uso degli indici, richiede troppe risorse di I/O, memoria e CPU dal server.

Comprendi che una query così universale che recupera tutte le colonne può essere dispendiosa. Alcuni dicono che sono utili perché consentono agli sviluppatori di utilizzare lo stesso bit di codice in più di un posto. Va bene se il costo coinvolto è limitato in considerazione. A volte la memorizzazione nella cache dei dati recuperati aiuta in questo contesto. Ma sii prudente, sfruttare le prestazioni è un lavoro elegante e un tale lusso potrebbe non avere spazio per le prestazioni.

La regola pratica è evitare tali query universali o mantenere un numero di colonne recuperato il più minimo possibile.

Troppa analisi dei dati

Le query restituiscono il risultato desiderato che va bene, ma a volte queste query sono scritte in modo tale che durante l'elaborazione è necessario esaminare troppi dati prima di generare risultati. Pertanto, in MySQL devi misurare in base alle seguenti metriche di costo:

  • Tempo di esecuzione
  • Righe esaminate
  • Colonne esaminate

È possibile ottenere una stima approssimativa del costo della query da queste metriche. Ciò riflette la quantità di accesso ai dati da parte di MySQL internamente per elaborare la query e la velocità di esecuzione della query. Poiché queste metriche vengono registrate nel registro delle query lente, è una buona idea esaminare e trovare query che analizzano troppi dati per restituire il risultato. Il database MySQL registra tutte le query che superano una determinata quantità di tempo di esecuzione nel registro delle query lente. Questo è il luogo ideale per cercare query lente e scoprire quanto spesso sono lente.

Un registro delle query lente si trova in genere in /var/log/mysql/mysql-slow.log

Tieni presente che potrebbe essere necessario impostare e abilitare la registrazione di query lente in mysqld.cnf file di configurazione come segue.

#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/mysql-slow.log
#long_query_time = 2 

Prima e con MySQL 5 c'erano gravi limitazioni, in particolare la mancanza del supporto per la registrazione a grana fine. L'unico sollievo è stato l'utilizzo di patch che abilitavano la registrazione. Tuttavia, la funzionalità è stata inclusa nei server MySQL 5.1 e versioni successive come parte della sua funzionalità principale.

Le query che richiedono troppo tempo per l'esecuzione non significano necessariamente che siano query errate. Il registro delle query lente offre semplicemente l'opportunità di esaminare le prestazioni della query e migliorarle il più possibile.

Query sulla ristrutturazione

Poiché hai l'opportunità di ristrutturare le domande problematiche, il tuo obiettivo principale dovrebbe essere quello di trovare una soluzione alternativa per ottenere l'effetto desiderato. Puoi trasformare la query nella sua forma equivalente tenendo presente l'effetto interno nel server MySQL durante l'elaborazione.

Una decisione nella progettazione delle query è se dovremmo preferire una query complessa al posto di più query semplici o viceversa. L'approccio convenzionale alla progettazione di database consiste nell'eseguire il maggior numero possibile di lavori con meno query. Il motivo è che una query grande/complessa è più conveniente in termini di stabilire una connessione al database. Il vantaggio della riduzione dei costi a favore di query complesse è l'utilizzo della rete, l'elaborazione/ottimizzazione delle query e l'utilizzo delle risorse. Ma questo approccio tradizionale non si adatta bene a MySQL. MySQL è progettato per gestire rapidamente la connessione e la disconnessione del database. Pertanto, stabilire la connessione, eseguire molte query più semplici e chiudere la connessione sembra più efficiente. Il recupero dei dati tramite più di una semplice query al posto di una grande e complessa è più efficace. Nota che la stessa idea potrebbe non essere applicata con altri database.

Conclusione

Questi sono alcuni suggerimenti rapidi per l'ottimizzazione delle query. Comprendi che, conoscendo le sintassi SQL, essere in grado di creare una query che recuperi il risultato desiderato non è sufficiente se si mira alle prestazioni della query. Comprendere l'accaduto sotto le query apparentemente semplici è fondamentale per scriverne una che non solo recuperi ciò che si desidera, ma infonda l'arte dell'ottimizzazione proprio da dove tutto inizia. Il dietro le quinte dell'elaborazione delle query fornisce un indizio importante per comprendere le prestazioni delle query e questa conoscenza è un must prima di un'incursione nel regno dell'ottimizzazione delle query.