SQL Tuning [Electronic resources] نسخه متنی

1.1 Why Tune SQL?

Let's begin with a basic
question: should someone tune the SQL in an application, and is that
someone you? Since you are reading this book, your answer is at least
moderately inclined to the positive side. Since it took me several
years to appreciate just how positive my own answer to this question
should be, though, this chapter lays my own viewpoint on the table as
an example.

Let's describe your application, sight-unseen, from
an admittedly datacentric point of view: it exists to allow human
beings or possibly another application to see, and possibly to enter
and manipulate, in a more or less massaged form, data that your
organization stores in a relational database. On the output data, it
performs manipulations like addition, multiplication, counting,
averaging, sorting, and formatting, operations such as those you
would expect to see in a business spreadsheet. It does not solve
differential equations or do any other operations in which you might
perform billions of calculations even on a compact set of inputs.
The work the
application must do after it gets data out of
the database, or before it puts data into the
database, is modest by modern computing standards, because the data
volumes handled outside of the database are modest, and the
outside-the-database calculation load per datapoint is modest.

Online applications and applications that produce reports for human consumption should produce data volumes fit for human consumption, which are paltry for a computer to handle. Middleware, moving data from one system to another without human intervention, can handle higher data volumes, but even middleware usually performs some sort of aggregation function, reducing data volumes to comparatively modest levels.

Even if the vast number of end users leads to high calculation loads
outside the database, you can generally throw hardware at the
application load (the load outside the database, that is), hanging as
many application servers as necessary off the single central
database. (This costs money, but I assume that a system to support,
say, 50,000 simultaneous end users is supported by a substantial
budget.)

On the other hand the
database behind a business application often examines millions of
rows in the database just to return the few rows that satisfy an
application query, and this inefficiency can completely dominate the
overall system load and performance. Furthermore, while you might
easily add application servers, it is usually much harder to put
multiple database servers to work on the same consistent set of
business data for the same application, so throughput limits on the
database server are much more critical. It is imperative to make your
system fit your business volumes, not the other way around

Apart from these theoretical considerations, my own experience in
over 13 years of performance and tuning, is that the
databasemore specifically, the SQL from the
applicationis the best place to look for performance and
throughput improvements.

Improvements to SQL performance tend to be the safest changes you can
make to an application, least likely to break the application
somewhere else, and they help both performance and throughput, with
no hardware cost or minimal cost at worst (in the case of added
indexes, which require disk space). I hope that by the end of this
book you will also be persuaded that the labor cost of tuning SQL is
minimal, given expertise in the method this book describes. The
benefit-to-cost ratio is so high that all significant database-based
applications should have their high-load SQL tuned.