我还要补充一点，除了理论上对数据库进行调优外，还应该使用跟踪SQL调用的分析器对应用程序进行分析。

尽管您的初衷是好的，但还是会有一些不好的调用潜入您的应用程序，通常会导致90%的性能相关问题。

在http://www.mysqlperformanceblog.com/上可以找到很多关于MySQL的技巧

http://www.javaperformancetuning.com/tips/jdbc.shtml http://www.google.com/search?q=database+performance+tuning

对于使用Oracle的人，我推荐这个链接.............

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/toc.htm

从我的Oracle数据库开发经验中，我发现，了解如何使用SQL，它是如何工作的，了解哪些是可用的(提供的函数，你不知道存在的子句或从上一个版本增强的子句)意味着我花更少的时间来调优SQL。

当我看到这种快速了解在Oracle下调优的SQL语句发生了什么时，我非常高兴。将下面的第一个SQL语句更改为SELECT语句，并保留该提示。

SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL;

SELECT * FROM TABLE(dbms_xplan.display_cursor( NULL, NULL, 'RUNSTATS_LAST'))
;

PLAN_TABLE_OUTPUT
-----------------------------------------------------
SQL_ID  5z36y0tq909a8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL

Plan hash value: 272002086

---------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
---------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS FULL| DUAL |      1 |      1 |      1 |00:00:00.02 |       3 |      2 |
---------------------------------------------------------------------------------------------


12 rows selected.

地点:

E-Rows是估计行数。 A-Rows是实际的行。 A-Time是实际时间。 缓冲区是实际的缓冲区。

如果估计的计划与实际执行存在数量级上的差异，那么您就知道有问题了。

首先，我要了解数据库在基本层面上是如何工作的。数据如何存储在磁盘上，创建索引做什么，查询计划优化如何工作，计划如何缓存，缓存的计划何时过期。

如果您能记住所有这些内容，那么关于调优的大多数建议似乎都是显而易见的。

这是一本关于MSSQL的好书

SQL Server内部结构