java之Database Performance Best Practices

java之Database Performance Best Practices


  • Spend time evaluating the best JDBC driver for the application.
  •   The best driver will often vary depending on the specific deployment. The same application may be better with one JDBC driver in one deployment and a different JDBC driver in a different deployment.
  •  If there is a choice, avoid ODBC and type 1 JDBC drivers.
  • Java applications will typically execute the same SQL statement repeatedly. In those cases, reusing prepared statements will offer a significant performance boost.
  •  Prepared statements must be pooled on a per-connection basis.
         Most JDBC drivers and Java EE frameworks can do this auto matically.
  • Prepared statements can consume a significant amount of heap.
        The size of the statement pool must be carefully tuned to pre vent GC issues from pooling too many very large objects.


  • Transactions affect the speed of applications in two ways: transactions are expensive to commit, and the locking associated with transactions can prevent database scaling.
  •   Those two effects are antagonistic: waiting too long to commit a transaction increases the amount of time that locks associated with the transaction are held. Especially for transactions using stricter semantics, the balance should be toward committing more frequently rather than holding the locks longer.
  •   For fine-grained control of transactions in JDBC, use a default TRANSACTION_READ_UNCOMMITTED level and explicitly lock data as needed.

  • Applications that process large amounts of data from a query should consider changing the fetch size of the data.
  •  There is a trade-off between loading too much data in the application (putting pressure on the garbage collector) and making frequent database calls to retrieve a set of data.

I’ve recommended using the setFetchSize() method here on the (prepared) statement
object, but that method also exists on the ResultSet interface. In either case, the size is
just a hint. The JDBC driver is free to ignore that value, or round it to some other value,
or anything else it wants to do. There are no assurances either way, but setting the value
before the query is executed is more likely to result in the hint being honored.
Some JDBC drivers also allow you to set a default fetch size when the connection is
created by passing a property to the getConnection() method of the DriverManager.
Consult your vendor’s documentation if that path seems easier to manage.


读书笔记:

Java Performance: The Definitive Guide
by Scott Oaks
Copyright © 2014 Scott Oaks. All rights reserved.
Printed in the United States of America.

你可能感兴趣的:(java之Database Performance Best Practices)