SQL查询性能优化(TimesTen)

Question

我需要一些关于TimesTen数据库查询优化的帮助。我使用Java分析器进行了一些度量，并发现了大部分时间占用的代码部分(此代码部分执行SQL查询)。奇怪的是，这个查询只会对某些特定的输入数据造成昂贵的代价。

下面是一个例子。我们有两个正在查询的表，一个表示要获取的对象(T_PROFILEGROUP)，另一个表示来自其他表(T_PROFILECONTEXT_PROFILEGROUPS)的多到多的链接。我们并不是在查询链接表。

这些查询是我在运行DB分析器时执行的(除了ID之外，它们是相同的)：

Command> select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
< 1169655247309537280 >
< 1169655249792565248 >
< 1464837997699399681 >
3 rows found.

Command> select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
< 1169655247309537280 >
1 row found.

这就是我在分析器里的内容：

12:14:31.147       1 SQL      2L    6C  10825P Preparing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272
12:14:31.147       2 SQL      4L    6C  10825P sbSqlCmdCompile ()(E): (Found already compiled version: refCount:01, bucket:47) cmdType:100, cmdNum:1146695.
12:14:31.147       3 SQL      4L    6C  10825P Opening: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.147       4 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.148       5 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.148       6 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.228       7 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:31.228       8 SQL      4L    6C  10825P Closing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1464837998949302272;
12:14:35.243       9 SQL      2L    6C  10825P Preparing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928
12:14:35.243      10 SQL      4L    6C  10825P sbSqlCmdCompile ()(E): (Found already compiled version: refCount:01, bucket:44) cmdType:100, cmdNum:1146697.
12:14:35.243      11 SQL      4L    6C  10825P Opening: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      12 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      13 SQL      4L    6C  10825P Fetching: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;
12:14:35.243      14 SQL      4L    6C  10825P Closing: select G.M_ID from T_PROFILECONTEXT_PROFILEGROUPS CG, T_PROFILEGROUP G where CG.M_ID_EID = G.M_ID and CG.M_ID_OID = 1466585677823868928;

很明显，第一个查询花费了将近100‘s，而第二个查询是立即执行的。这与查询预编译无关(第一个也是预编译的，因为前面也有相同的查询)。这里使用的所有列都有DB索引：T_PROFILEGROUP.M_ID、T_PROFILECONTEXT_PROFILEGROUPS.M_ID_OID和T_PROFILECONTEXT_PROFILEGROUPS.M_ID_EID。

我的问题是：

• 为什么查询同一组表对于不同的参数产生如此不同的性能？
• 这里涉及哪些指数？
• 有任何方法来改进这个简单的查询和/或数据库使它更快吗？

更新：给出大小的感觉：

Command> select count(*) from T_PROFILEGROUP;
< 183840 >
1 row found.

Command> select count(*) from T_PROFILECONTEXT_PROFILEGROUPS;
< 2279104 >
1 row found.

Answer 1

我不熟悉TimesTen，但假设它与其他关系DB一样工作(内存中除外)，一个可能的原因是T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID或T_PROFILEGROUP.M_ID列上没有索引，或者二叉树索引不平衡。

如果没有索引，结果将取决于数据的顺序，即找到它们的速度。

在具有大量数据的表中，我经历过不平衡的二叉树索引，这会导致问题，因为树的一边要比其他的大得多。在这种情况下，重新构建索引可以重新平衡树。

我不能诚实地说，这是否适用于从未使用过的TimesTen，而且我的网络搜索也没有提供多少信息。

Answer 2

我对TimesTen数据库并不太熟悉，但是由于它在这里还不到十分之一秒，它是否只是这两个查询的四舍五入的差异，还是某种打嗝呢？

下面是一个链接，它介绍了一些性能调优TimesTen DB的方法。它有一些一般的信息(使用准备等)。以及有关优化特定查询的信息。希望能帮上忙。

Answer 3

我粗略地打赌，第一个查询将数据从磁盘或虚拟内存中提取到实际内存中，而第二个查询可以利用这一点。

你能用三个(或十个)来运行这个吗？查询并返回报告？