Beginning SQL

The point of all the discussion of cache is simply that you can tune your application to your heart’s content,
but if the hardware infrastructure doesn’t support the application, all of your work yields minuscule
improvements in the application speed and could cost a lot of money to get that minuscule
improvement. It is critical to look at the big picture and understand exactly where the bottlenecks lie.
Attack the bottlenecks in order of severity, quitting when the application runs at an acceptable speed.
Okay, so you have determined that application bottlenecks exist in the application itself, and your hardware
is sufficient. What next?
Tuning SQL
There is an axiom in programming that says that 90 percent of the time is spent in 10 percent of the code.
If you want to make your program run faster, you only need to optimize that 10 percent of the code. SQL
is programming and thus can be viewed in the same manner, and it is very useful to do so. Very few
databases have only a few queries. Databases often service entire applications, and those applications
have pieces and parts that query the database. Often the applications have entire subprograms, each
with their own sets of queries. You need to do a little investigative work and discover which specific
piece is causing the slowdown.
You might be saying, “Yes, but that doesn’t matter, just show me how to optimize a query,” but that is
very much putting the cart before the horse. Optimizing a query involves a set of techniques and uses a
set of tools, which you get to shortly, but before you do, it is important to understand that you should
not just take a shotgun approach to the subject of optimization. In the end, the intent is usually to make a
process run faster, which in the end may mean making a query run faster, but which query? Since a process
may be made up of dozens of subqueries, simply starting at the top and attempting to optimize
every query in the process is an exercise in frustration, and perhaps in futility.
Given the nature of applications, it’s impossible to tell you specifically where to look to discover what
needs to be optimized, so you need to always keep the preceding advice in mind and your stopwatch in
hand. As you get into production systems, you may find that you are trying to make a whole process run
faster, and that involves breaking that process down into pieces and then timing the pieces. As you discover
the high-cost pieces, you may very well be able to break those down into smaller pieces looking
for high-cost pieces, and so forth, until you end up with one or a small number of queries that represent
that 10 percent where the process is spending 90 percent of its time. Once you get there, what you learn
next in this chapter becomes useful.
What Does SQL Tuning Mean?
Database Tuning
Tuning an individual query means examining the structure of the query (and subqueries), the SQL syntax,
to discover whether you have designed your tables to support fast data manipulation and written
the query in an optimum manner, allowing your DBMS to manipulate the data efficiently. Queries do
many things, from adding entirely new records to tables, to updating existing records, to pulling data
out of multiple related tables for reporting purposes. It is this last part that many people think of when
discussing optimizing queries, but in fact, a database must be viewed as a whole entity or you risk
speeding up one piece while crippling another. As this chapter demonstrates, there are techniques (particularly
when optimizing other people’s queries) that are essentially free, while others (specifically creating
new indexes) can be applied only at a price.
355