C H A P T E R
14
Indexing
Pratie Exerises
14.1
Indies speed quer y proessing, but it is usually a bad idea to reate indies on
ever y attribute, and ever y ombination of attr ibutes, that are potential searh
keys. Explain why.
Answer:
Reasons for not keeping indies on every attribute inlude:
Ever y index requires additional
CPU
time and disk
I/O
overhead dur ing
inser ts and deletions.
Indies on non-primar y keys might have to be hanged on updates, al-
though an index on the pr imar y key might not (this is beause updates
typially do not modify the primar y -key attr ibutes).
Eah extra index requires additional storage spae.
For quer ies whih involve onditions on several searh keys, eieny
might not be bad even if only some of the keys have indies on them.
Therefore, database per for mane is improved less by adding indies when
many indies already exist.
14.2
Is it possible in general to have two lustering indies on the same relation for
dierent searh keys? Explain your answer.
Answer:
In general, it is not possible to have two primar y indies on the same relation
for dierent keys beause the tuples in a relation would have to be stored in
dierent order to have the same values stored together. We ould aomplish
this by storing t he relation twie and dupliating all values, but for a entralized
system, this is not eient.
14.3
Construt a B
+
-tree for the following set of key values:
99
评论5