2015-04-15 30 views
7

Ho una tabella, con un certo numero di colonne, ho applicato un determinato algoritmo ed è stato in grado di dividere la tabella esistente in 5 tabelle. Ecco l'immagine dei database dopo l'applicazione dell'algoritmo. enter image description here Quindi ho diviso la tabella stsi in base, card_type, country, cvv,. La STSI aveva i seguenti attributi: id, nome, telefono, email, filiale, nazione, ac_no, credit_card, card_type, cvv. Quindi, dopo l'applicazione dell'algoritmo, la tabella di base ha l'id, il nome, l'email, il ramo, ac_no, credit_card, phone. E gli attributi rimanenti sono card_type, country e cvv. Questi attributi hanno una tabella separata ciascuno. Diciamo per il racconto cvv. Gli attributi saranno id e cvv. L'ID sarà primary_key nella tabella di base. Così come per l'immagine sono stato in grado di ridurre il numero di righe nelle nuove tabelle formate poiché cvv ha 7829 righe anziché 9000 come in STSI, a causa dei valori null in STSI. La performance è stata aumentata rispetto allo spazio. Ma non sono in grado di aumentare la complessità del tempo.Come migliorare le prestazioni nel seguente scenario

Ho inteso che le tabelle più recenti dovrebbero avere una minore complessità temporale, in quanto hanno un numero di righe relativamente minore. Ma non sono in grado di ottenere alcun aumento delle prestazioni. Ho provato l'indicizzazione, ma non ha comportato alcun guadagno in termini di prestazioni. cosa posso fare per aumentare le prestazioni rispetto al tempo, quando eseguito su nuovi tavoli.

ps: Le query sono
select id,cvv from stsi - 0.0005 seconds select id,cvv from cvv - 0.0005 seconds
Spero che seconda query dovrebbe prendere meno tempo!

+4

Si prega di inviare la query che ha prestazioni ridotte. – Alexander

+0

Le query mostrano prestazioni uguali sia in STSI che in tabelle più recenti. 'Dire selezionare cvv da STSI, selezionare cvv da cvv' stanno dando gli stessi orari – gates

+0

.5 millisecondi non è un problema di prestazioni, e la tua" ottimizzazione "è completa overkill. – Alexander

risposta

5

A 0,5 ms, è probabile che il limitatore sia il tempo di risposta effettivo del sistema (lettura del disco, elaborazione CPU, ecc.) E non la query stessa. Nessuna quantità di ottimizzazione riduce il tempo di risposta.

Come regola generale, quando si esaminano semplici query di selezione (selezionare val1, val2 dalla tabella), il più grande driver di prestazioni sarà la configurazione di sistema sottostante (configurazione del disco e disponibilità di memoria principalmente) e progettazione del database .

L'utilizzo di una buona indicizzazione può aiutare a ridurre i tempi di risposta riducendo la quantità di dati da leggere per produrre risultati. Nell'esempio precedente, collocare un indice sulla tabella CCV composto da ID e CCV probabilmente produrrebbe una risposta più rapida man mano che il set di dati cresce.

Suppongo, in base al tuo audace, che la tua domanda derivi dal fatto che STSI ha più file di CCV e ti aspettavi che CCV fosse più veloce. In realtà è probabile che si veda il primo vincolo qui (configurazione del sistema) e non la progettazione del database.

Un mezzo millesimo di secondo è dannatamente veloce. Non so che dovresti aspettarti di vedere qualcosa di più veloce su hardware di fascia consumer, anche se stai confrontando una tabella da 9000 righe con una tabella da 9 righe.

+1

Sì, sono d'accordo con la maggior parte dei tuoi punti. E sì, il mio è un laptop, che è di nuovo un consumatore. Secondo i tempi interessati, 0,5 millisecondi sono veloci. quindi voglio girare un po 'questo, c'è un modo per ridurre il tempo di risposta di STSI? So che questo tipo batte il punto di questo. Ma voglio sapere se esiste un modo! @tdavis – gates

+0

Si potrebbe provare ad aggiungere un indice a STSI su ID e CCV, ma dubito che vedrete alcuna differenza. – TDavis

+1

Ho provato, ma nessuna differenza come hai menzionato. Ma a che punto riuscirò a vedere una differenza aggravante. Come 1 milione di set di dati, istanza Amazon, qualcosa? – gates

Problemi correlati