Il partizionamento è mai un'opzione per migliorare le prestazioni. Il meglio che puoi sperare è avere prestazioni alla pari con la tabella non partizionata. Di solito si ottiene una regressione che aumenta con il numero di partizioni. Per le prestazioni sono necessari indici, non partizioni. Le partizioni sono per le operazioni di gestione dei dati:ETL, archiviazione ecc. Alcuni sostengono che l'eliminazione della partizione sia un possibile aumento delle prestazioni, ma per qualsiasi cosa l'eliminazione della partizione può dare il posizionamento della chiave dell'indice iniziale sulla stessa colonna della colonna di partizionamento darà risultati molto migliori.
Quella query necessita di un indice su State . Altrimenti è una scansione della tabella e scansionerà l'intera tabella. Una scansione di una tabella su una tabella partizionata è sempre più lenta di una scansione su una tabella non partizionata della stessa dimensione. L'indice stesso può essere allineato sullo stesso schema di partizione, ma la chiave iniziale deve essere State .
Il parallelismo non ha nulla a che fare con il partizionamento, nonostante il comune malinteso del contrario. Sia le scansioni dell'intervallo partizionato che non partizionato possono essere utilizzate un operatore parallelo, sarà la decisione di Query Optimizer.
No
Un indice aiuterà. Se l'indice deve essere allineato, deve essere partizionato. Un indice non partizionato sarà più veloce di uno partizionato, ma il requisito di allineamento dell'indice per le operazioni di attivazione/disattivazione non può essere aggirato.
Se stai esaminando il partizionamento, dovrebbe essere perché devi eseguire operazioni di switch-in switch-out rapide per eliminare i vecchi dati oltre il periodo della politica di conservazione o qualcosa di simile. Per le prestazioni, devi guardare agli indici, non al partizionamento.
