Beginning SQL
Beginning SQL Beginning SQL
Chapter 13 64k Block 64k Block Figure 13-5 Data Table Record 8k Record 8k Table scans can cause absolutely huge performance hits or may not impact performance much at all. Imagine a table of 60 million records with dozens of fields, where the DBMS has to read every data record off the disk to examine the contents of a single field looking for matches. This operation could take hours or even days and of course trashes the various system caches. In another case, however, you may be scanning a table of just 100 records with only two or three columns. Again, the DBMS has to pull all the records, but the size of the task is so much smaller that the impact on the query may be negligible. In the first case, the probability of the data being in any of the various caches is negligible; in fact, it is simply impossible. In the second case, the data may very well be in a cache, and in fact if the table is scanned repeatedly, the data may very well stay in a cache permanently. Another impact that sometimes is not considered is the impact of a large table scan on the various system caches. Because so much data is being read off the disk, it is possible to flush data that would otherwise have remained in the cache forever and replace it with data used only this one time. Obviously, all that other data is reread and placed back in the cache once the table scan is finished since the normally cached data is used so often. When Table Scans Help, Hurt, or Don’t Matter 362 Table scans can be useful when the table is small, and particularly when the table is used often enough to remain in the cache. Table scans tend to cause linear performance degradation as the table size grows. Thus, table scans might work perfectly well when a particular table is new with not much data, but they get slower and slower as new records are added to the table. Keep this in mind if you build queries with WHERE conditions or joins on nonindexed columns of active tables. Performance may be quite acceptable initially, but it may worsen over time. If the table is a static table, such as a state or country lookup table, the performance might be fine and never changes since new states are so rarely added to the table.
- Page 712: Chapter 12 Privileges Privileges ar
- Page 716: Chapter 12 338 You could then give
- Page 720: Chapter 12 You might implement this
- Page 724: Chapter 12 Another shortcut, using
- Page 728: Chapter 12 As you can imagine, givi
- Page 732: Chapter 12 The situation gets a lit
- Page 736: Chapter 12 Summary Database securit
- Page 740: Chapter 13 robust, fault-tolerant m
- Page 744: Chapter 13 Gigahertz Networks or Co
- Page 748: Chapter 13 Database Cache 354 In ad
- Page 752: Chapter 13 Again, the shotgun appro
- Page 756: Chapter 13 358 Figure 13-3 Leaf Ind
- Page 760: Chapter 13 Try It Out Dropping Inde
- Page 766: Tuning Tips The following list cont
- Page 770: Database Tuning Exercises 1. Create
- Page 776: Appendix A Exercise 2 Solution 368
- Page 780: Appendix A ( 8, ‘Jack’, ‘John
- Page 784: Appendix A ZipCode, Email, DateOfJo
- Page 788: Appendix A Exercise 3 Solution Firs
- Page 792: Appendix A 376 Figure A-1 ISBN is a
- Page 796: Appendix A Chapter 5 Exercise 1 Sol
- Page 800: Appendix A 380 You might receive sl
- Page 804: Appendix A 382 You should use the f
- Page 808: Appendix A Your answer may differ,
- Page 812: Appendix A WHERE (SELECT COUNT(*) f
Chapter 13<br />
64k Block<br />
64k Block<br />
Figure 13-5<br />
Data Table<br />
Record 8k<br />
Record 8k<br />
Table scans can cause absolutely huge performance hits or may not impact performance much at all.<br />
Imagine a table of 60 million records with dozens of fields, where the DBMS has to read every data<br />
record off the disk to examine the contents of a single field looking for matches. This operation could<br />
take hours or even days and of course trashes the various system caches. In another case, however, you<br />
may be scanning a table of just 100 records with only two or three columns. Again, the DBMS has to pull<br />
all the records, but the size of the task is so much smaller that the impact on the query may be negligible.<br />
In the first case, the probability of the data being in any of the various caches is negligible; in fact, it is<br />
simply impossible. In the second case, the data may very well be in a cache, and in fact if the table is<br />
scanned repeatedly, the data may very well stay in a cache permanently.<br />
Another impact that sometimes is not considered is the impact of a large table scan on the various system<br />
caches. Because so much data is being read off the disk, it is possible to flush data that would otherwise<br />
have remained in the cache forever and replace it with data used only this one time. Obviously, all<br />
that other data is reread and placed back in the cache once the table scan is finished since the normally<br />
cached data is used so often.<br />
When Table Scans Help, Hurt, or Don’t Matter<br />
362<br />
Table scans can be useful when the table is small, and particularly when the table is used often enough<br />
to remain in the cache. Table scans tend to cause linear performance degradation as the table size grows.<br />
Thus, table scans might work perfectly well when a particular table is new with not much data, but they<br />
get slower and slower as new records are added to the table. Keep this in mind if you build queries with<br />
WHERE conditions or joins on nonindexed columns of active tables. Performance may be quite acceptable<br />
initially, but it may worsen over time. If the table is a static table, such as a state or country lookup table,<br />
the performance might be fine and never changes since new states are so rarely added to the table.
Change language