Partitionering er aldrig en mulighed for at forbedre ydeevnen. Det bedste, du kan håbe på, er at have en ydeevne på niveau med et ikke-opdelt bord. Normalt får du en regression, der stiger med antallet af partitioner. For ydeevne har du brug for indekser, ikke partitioner. Partitioner er til datastyringsoperationer:ETL, arkivering osv. Nogle hævder, at partitionseliminering er mulig præstationsforøgelse, men for alt, kan partitionseliminering give at placere den førende indeksnøgle på samme kolonne som partitioneringskolonnen, vil give meget bedre resultater.
Denne forespørgsel skal have et indeks på State . Ellers er en tabelscanning, og vil scanne hele bordet. En tabelscanning over en opdelt tabel er altid langsommere end en scanning over den samme størrelse ikke-opdelte tabel. Selve indekset kan justeres på det samme partitionsskema, men den førende nøgle skal være State .
Parallelisme har intet at gøre med opdeling, på trods af den almindelige misforståelse om det modsatte. Både partitionerede og ikke-partitionerede rækkeviddescanninger kan bruge en paralleloperator, det vil være Query Optimizer-beslutningen.
Nej
Et indeks vil hjælpe. Hvis indekset skal justeres, skal det partitioneres. Et ikke-opdelt indeks vil være hurtigere end et opdelt indeks, men kravet til indeksjustering for ind-/udkoblingsoperationer kan ikke omgås.
Hvis du kigger på partitionering, burde det skyldes, at du skal udføre hurtige udskiftningsoperationer for at slette gamle data efter en opbevaringspolitikperiode eller noget lignende. For ydeevne skal du se på indekser, ikke på partitionering.