Lanciare un'eccezione se una query non utilizza un indice

My initial idea is to throw an exception if any query doesn't use an index so it has to be taken care of in devel but to continue to log the large/slow queries so we can see long term where the slowness is.

Penso che non dovresti farlo perché:

• L'applicazione non può mai sapere se una query ha utilizzato un indice o meno

• Le eccezioni riguardano errori reali non per i controlli delle prestazioni

• Le prestazioni scadenti delle query possono essere attribuite agli indici ma non agli indici da solo. Potrebbe essere perché la quantità di dati restituiti è così grande, o il database è progettato male per lo scopo richiesto, o vengono letti troppi colonne che non sono necessari, ecc. Inoltre, riscrivendo la query può far sì che usi un indice (query indicizzabili e non indicizzabili)

• L'aggiunta di indici a volte rallenta le prestazioni di inserti e aggiornamenti, quindi fai attenzione

Per risolvere questo problema, è necessario:

• Identifica le query con scarse prestazioni

• Assicurati che il problema sia in SQL

• Assicurati che vengano recuperate solo le righe e le colonne necessarie

• Esegui il profilo delle query utilizzando uno strumento di profilazione e intraprendi l'azione necessaria in base ai risultati.

Controlla anche con Forum DBA

In ogni singolo caso vuoi essere sicuro che venga utilizzato un indice? Certo, la maggior parte delle volte dovresti usare un indice. Ma a volte non ne vale la pena. Quindi lanciare un'eccezione potrebbe essere problematico in quei casi.

A volte vorrai semplicemente inserire una query per ottenere i risultati corretti prima di assicurarti che sia correttamente ottimizzato e che usi un indice. Lanciare un'eccezione costringe l'ottimizzazione prima di aver verificato la correttezza.

Che ne dite di rendere le query di lunga durata più fastidiose nell'ambiente di sviluppo? Popup un messaggio che dice "query a esecuzione prolungata". L'app non morirà e potrai testare la tua funzionalità, ma noterai che ha bisogno di un po 'di lavoro.

Tendo a incorporare strumenti di qualche forma in tutte le app che ho creato. JavaMelody è abbastanza carino e non intrusivo e fornisce una buona strumentazione di livello JDBC. Se stai usando Oracle, mostra anche i piani di esecuzione per tutte le query.

Direi che è sufficiente aumentare la gravità della registrazione di tali problemi. Non penso che dovresti creare un'eccezione in questo caso, a meno che tu non possa configurare il tuo progetto in modo che lo faccia solo negli ambienti di sviluppo.

Hai un modo per catturare i colpevoli, ma causare un errore è una cattiva idea. È anche un falso senso di sicurezza. Un progetto di query potrebbe non cambiare affatto, ma i dati possono cambiare e influire sulle prestazioni. A seconda della mancanza di statistiche RDBMS può causare problemi di prestazioni. Continuerete a monitorarli comunque. Solo perché una query utilizza almeno un indice non significa che non dovrebbe utilizzare gli altri.

Questo è un altro modo per creare cattivo sangue con i tuoi programmatori e utenti. Chi viene davvero punito qui?

Capisco la tua frustrazione. Ma penalizzare l'utente con le eccezioni potrebbe non essere una buona idea in questo caso.

Quello che puoi fare è:

Ogni volta che trovi questo problema nel codice, puoi chiamare un registratore speciale che dice PerformanceIssueLogger.log che registrerà questi problemi in un log diverso con la query specifica che potrai scansionare in seguito e risolvere i problemi.

Ancora meglio, puoi incapsulare la logica che PerformanceIssueLogger.log , che può generare un'eccezione oltre all'accesso al file se environment != prod.

Tali regole a priori non hanno molto senso. In una prima fase, registra quali query richiedono quanto tempo e con quale frequenza vengono chiamate.

Quindi puoi veramente vedere, quali query sono un problema efficace e lavorare per risolverlo. L'ottimizzazione delle prestazioni è possibile solo dopo aver determinato i colli di bottiglia attraverso una corretta profilazione. Una volta scoperto un collo di bottiglia, devi prima capirlo e quindi valutare le diverse opzioni. Quando si tratta di SQL, lo slapping degli indici sulle tabelle coinvolte è un'opzione. Denormalizzazione, sharding o caching (attraverso memcache o redis) sono altri. Proprio come non esiste una semplice regola che ti dirà quante risorse una determinata query mangerà (perché ciò dipende da cose che puoi speculare o semplicemente misurare), non esiste una semplice regola su come ridurre il consumo di risorse. / p>