- Authors:
- Peter Gulutzan,
- Trudy Pelzer
From the Book: A poorly performing database application can cost each user time, and have an impact on other applications running on the same computer or the same network. The purpose of this book is to help you improve the performance of your SQL database. It is not an introduction to SQL syntax, not a tuning manual for a specific SQL implementation, and not a guide to design or data modelling. Instead, 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. Topics that will give you the flavor include: "How to change a query so it will go faster", "What an index does", and "Shifting work from the server to the client." 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. Client/server programmers and consultants need to appreciate what can happen when the DBMS changes, orthe most challenging situationthe DBMS is unknown. So we tested all the ideas in this book on eight well-known DBMSs. A good DBMS already contains a good optimizer. Yet you have picked up a book that promises to help you do your own tuning. That means that either you don't know something ... or you do know something: You don't know that your DBMS is good. You know that even good tools work better in skilled hands. You don't know that your DBMS is good ... That would be true if you're a student, or new on the job. That would especially be true if you're writing queries or programs that should work on more than one DBMS. You're most likely toencounter one of the DBMSs with the largest market shares (based on figures for the year 2000): Oracle 33.8% IBM 30.1% (prior to acquisition of Informix) Microsoft 14.9% Sybase 3.2% Informix 3.0% Data from: Gartner Dataquest (May 2001) You might also run into DBMSs that are popular for web work (like MySQL), for work with Borland products (like InterBase), for desktops (like Access), for mobile and Java interfacing (like Cloudscape), for embedded systems (like Solid), or a host of small fry (like mSQL and gadfly). This book tries to be useful for the common denominator in all products. To use automotive analogies, it's not a "mechanic's guide to tuning the 1999 Cadillac" book, it's a "driver's guide to optimizing performance of modern cars" bookeven if you have a manual transmission. You know that even good tools work better in skilled hands ... Everybody has heard of sluggish SQL queries, or even whole systems, that some hero(ine) improved with small effort. Usually the improvement is small too, so we will avoid extravagant promises. But we will make you the following guarantees: You will be able to follow our arguments without deep thinking or hard work. All we assume is that you have basic knowledge of programming and standard SQL syntax. In fact, you can read this book on a plane or at the beach. All of our observations have been confirmed by tests on real DBMSs within the last several months. We know that "optimizing" is very different from "over-clocking" and will only discu techniques. One accusation that could be levelled, and to which we plead guilty, is that some of our material is ad-hoc instead of general principles. Of course! There are only a few general principles in DBMS optimization: First, do no harm. (Actually that's from Hippocrates' ancient manual on medical treatments. It applies to anybody fixing what ain't really broke.) Get more memory, add indexes, re-cable the network. (If you can influence the environment like that, then do so.) Design right in the first place. Understand the query. Instead of general principals, we will be looking at what can be done with what's likely to be at hand. If we descend sometimes to mere tips and warnings about traps, that's because we've seen over the years that examples of real situations can help people realize what the general rules are. As has often been observed, tips should be based on principles. The DBMSs that we looked at while preparing this book include IBM DB2, Informix, Ingres II, InterBase, Microsoft SQL Server, MySQL, Oracle, and Sybase (MS-WindowsNT versions). Each was installed and tested using the default switches recommended in the vendors' instructions. To avoid favoring any vendor's idiosyncrasies, all SQL examples in this book are written in ANSI/ISO Standard SQL:1999. Host-language examples are written in C plus ODBC, or Java plus JDBC. Your DBMS is your pal. We won't counsel you to subvert it, be paranoid about it, or insult it by assuming it's stupid. Rather, as you would with a pal, you should try to get to know it better, and help it to help you.
Cited By
Bujdei C, Moraru S and Dan S Optimize databases for health monitoring systems Proceedings of the 1st international conference on PErvasive Technologies Related to Assistive Environments, (1-8)- Lodhi F and Ghazali M Design of a simple and effective object-to-relational mapping technique Proceedings of the 2007 ACM symposium on Applied computing, (1445-1449)
Index Terms
- SQL Performance Turning
Recommendations
SQL: 1999, formerly known as SQL3
For several years now, you've been hearing and reading about an emerging standard that everybody has been calling SQL3. Intended as a major enhancement of the current second generation SQL standard, commonly called SQL-92 because of the year it was ...
Friedrich D. Dominicus
Databases are unquestionably the backbone of data processing, and relational databases lead the pack. Relational databases are inseparable from the data manipulation and query language SQL. As a result, the audience of this book will be very large. That audience is apparently intended to be programmers, more than academics. The book can be read from cover to cover, or the reader can focus on a chapter of interest. All the chapters have a similar structure: the topic is introduced, the authors explain what the topic is about, and then sometimes show a simple model to explain why things work in a certain way. Each chapter ends with a sub-chapter that the authors call “The bottom line.” There, they reiterate their descriptions with simple sentences, such as, “The left side of a search should be a simple column name; the right side should be an easy-to-look-up value” (p. 23). This information alone should be enough to enable the impatient reader to improve his or her code. The book consists of 17 chapters. It starts with simple queries, and continues with a description of the use of ORDER BY and GROUP BY constructs, joins, sub-queries, columns, and tables. A whole chapter is reserved for indices. The next three chapters deal with stored procedures, and database access through open database connectivity (ODBC) and Java database connectivity (JDBC). The following chapter is about optimizing data changes through insert, update, or delete operations. Lock handling is dealt with after that, followed by client server applications, and, finally, a discussion of the implications of using cost-based optimizers. Appendix A suggests some further reading, and Appendix B is the glossary. The book ends with a useful index. The authors consider a change to be an improvement if the performance gain is over five percent. These figures do not involve absolute numbers, but rather relative ones. If half of the “Big Eight Databases” (p. 3) gain by a restructuring, the authors grade this change as “Gain: 4/8.” The databases that actually improve are not listed explicitly, so readers cannot be sure if the change would be beneficial to them. The authors do insure, however, that the outcome won’t be worse (p. 7). They apparently do not actually run benchmarks and provide the results. Some database vendors, however, do forbid such benchmarks explicitly. Readers should have basic knowledge of SQL or another programming language. The text is neither “hard,” nor formal. The authors’ choice of databases to cover in the book includes more than 80 percent of the whole database market. The book is well written, and the advice given seems to be sound. The text has been carefully proofread; I remember only one obvious error in the given listings. What I would like to have found is some sort of overall strategy guide, which would say: “If in doubt, first start optimizing there, then there,” and so on. I think the authors’ advice would have ben efited by being bundled and categorized, and not just put in chapters. A “bottom line” for all the given suggestions and their gains would have helped. I think anyone interested in optimizing database usage should get this book, and place beside it a decent book about SQL, as well as the manuals from your database vendor. I like the book and will use it for my work. The authors have shown that, with just a little care, things can be improved. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.