- Paperback: 528 pages
- Publisher: Addison-Wesley Professional; 1 edition (September 20, 2002)
- Language: English
- ISBN-10: 0201791692
- ISBN-13: 978-0201791693
- Product Dimensions: 7.3 x 1.2 x 9 inches
- Shipping Weight: 1.8 pounds (View shipping rates and policies)
- Average Customer Review: 11 customer reviews
- Amazon Best Sellers Rank: #1,450,001 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
SQL Performance Tuning 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
The Amazon Book Review
Author interviews, book reviews, editors picks, and more. Read it now
Frequently bought together
Customers who viewed this item also viewed
From the Back Cover
SQL Performance Tuning is a handbook of practical solutions for busy database professionals charged with managing an organization's critically important data. Covering today's most popular and widely installed database environments, this book is an indispensable resource for managing and tuning SQL across multiple platforms.
Packed with tips, techniques, and best practices, this hands-on guide covers SQL commands and queries over a wide range of conditions and environments. Every facet of the SQL environment is covered, from concurrency control to optimization—and every issue in between. The book includes an overview of each of the most widely used database management systems (DBMS) and provides tuning tips for common day-to-day situations.
Topics covered include:
Whether you are a programmer, consultant, or user, you will find SQL Performance Tuning an indispensable guide to optimizing SQL performance across today's popular database environments.
Throughout SQL Performance Tuning , ideas and techniques are tested on a variety of popular SQL environments, including IBM DB2, Informix, Ingres, InterBase, Microsoft SQL Server, MySQL, Oracle, and Sybase ASE. The book's practical examples are written in ANSI/ISO Standard SQL: 1999.
About the Author
Peter Gulutzan is a principal of Ocelot Computer Services Inc. in Alberta, Canada. Peter is a technical writer and computer programmer who has worked with SQL since 1986. With Trudy Pelzer, he has written three books, Optimizing SQL (CMP Books, 1994), Optimizing C with Assembly Code (CMP Books, 1995), and SQL-99 Complete, Really (CMP Books, 1999).
Trudy Pelzer is a principal of Ocelot Computer Services Inc. in Alberta, Canada. Trudy is a technical writer and computer programmer who has worked with SQL since 1986. With Peter Gulutzan, she has written three books, Optimizing SQL (CMP Books, 1994), Optimizing C with Assembly Code (CMP Books, 1995), and SQL-99 Complete, Really (CMP Books, 1999).
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
"SQL Performance Tuning" changed my perception of that; I was hooked just after just a few sentences. The language, the obvious depth of the authors' knowledge, the wide and careful coverage of all related issues, including the very fundamentals of the relational databases are presented as needed; and mostly, the enjoyably right balance between the theory and practice makes this book an outstanding read. I have not read most of it yet, but I am very excited about what I will find in the rest of it, even if it is something that I think I know well.
It's unfortunate, but perhaps unavoidable, that some details (e.g. lack of information on transactions and subselects in MySQL) where out-of-date by the time the book was published. It's also unfortunate that the authors were prevented by vendor license agreements from providing performance hard numbers.
Don't get this book to learn how to optimize for a particular vendor's database. Study it to broaden your skills.
...we've written it for users and programmers who want to improve SQL performance, no matter what brand of SQL they use. In this book, you'll find tuning tips for common situations... Rather than exploiting the unique features of a single DBMS, we're going to give you ideas that are good for all of the major SQL DBMSs.
Sounds good, but !
The biggest idea behind this book is that the authors took 8 most common databases (as per 2002: DB2, Informix, Ingres, Interbase, MS SQL, MySQL, Oracle, Sybase) and sort of compared them on many different subjects. I said "sort of" because you won't find specific recommendations like "DB2 does this better", or "this makes the query faster on Oracle". Instead, the authors came up with this idea - upon each discussed topic they summarize the gain that you might possibly get from using that particular technique should you be using it on _all_ of the 8 databases. They put it like:
which means that with the discussed trick in place, x out of 8 databases performed better (and the rest showed no improvement).
Two things make it break - (1) there is only so many tricks that improve on most databases (it's commonly 3/8) and (2) there is no way to tell which of 8 showed an improvement.
And so, how does it help me as a database administrator and developer ? I only work with 2, may be 3 specific database servers and there is no way to tell whether _they_ gained from that trick or not. All I can do is to keep all tricks in mind, apply them all anyway and hope it was my database that had an improvement. Or, I can re-run tests and see for myself.
The word about tests - the authors did run all the tests on the same single CPU Windows NT machine and specifically say:
We should explain that all timing tests for this book were done with a single-CPU computer, so comparisons between DBMSs would be misleading. The results wouldn't give full points to the DBMS with the best threading mechanisms.
This book would make a good source for trivia questions. Tricks and tips all around, but many discussions are too short to be of any use and end up with catch-it-all rules.
Chapter 17: Cost-based optimizers:
About 10 pages. Says that cost-based and rule-based optimizers are different and CBO peform better because they use real statistics. And so you should update statistics and use EXPLAIN and optimizer hints. That's all. Oh no, really ?
Chapter 11. Stored procedures.
Shows very reasonably and truthfully why SPs are useful and better in many situation and what the gotchas are. But then again
When parameter passing is by value, the DBMS usually makes a local copy ... That leads inevitably to the bad idea of declaring parameters to be "input/output" even when they're merely "input" parameters. The trick ... is that an "input/output" parameter value is not recopied down the line if stored procedure #1 calls stored procedure #2 ... it saves you space and copying time.
Bad be the idea or not, passing large amounts on a stack is certainly wrong, not only for SPs and indicates poor design. Otherwise, if you are passing small arguments, and want to optimize out the copying of a single int or varchar - what kind of a system is that ? I mean - you are calling an SP in a database. It begins a transaction, processes a lot of rows, does all the usual DB stuff and commits. And you are saving a single memory copy here ?
And the really performance-wise important topics may be mentioned but skipped, ex.
Chapter 10: Foreign Keys
It's technically possible that a CHECK constraint will not be violated at the time you update a row, but it will be violated by the time the SQL statement ends ... Because of these possibilities, ... DBMS will wait until the end of the statement before testing a constraint for violations. Thus, every row has to be accessed twice-once to change it, and a second time later on to test for constraint violations.
Now, _that_ would be a huge performance hit sometimes. Any discussion ? Clues or hints may be ? Nope. Well, thanks for mentioning anyway (and I'm serious right now).
The book lacks any hardware-related details, ex. how CPU, memory or I/O affect things. It lacks any database-specific details. It lacks any common approach to optimization, there is no single direction in which it leads you.
Therefore, here is my bottom line for this book - a good overview, yes. Many interesting and fascinating details, yes. A lot of hints, oh yes ! Detailed, sometimes. Practical, uhm, unlikely.