SQL查询性能优化（TimesTen）

Question

我需要一些有关TimesTen数据库查询优化的帮助。 我使用Java分析器做了一些测量，发现代码部分占用大部分时间（此代码部分执行SQL查询）。 奇怪的是，此查询仅对某些特定输入数据变得昂贵。

这是一个例子。 我们有两个表正在查询，一个表示我们想要获取的对象（ T_PROFILEGROUP ），另一个表示来自其他表（ T_PROFILECONTEXT_PROFILEGROUPS ）的多对多链接。 我们不是在查询链表。

这些是我在运行DB profiler时执行的查询（除了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毫秒，而第二个查询立即执行。 它不是关于预编译的查询（第一个也是预编译的，因为之前发生过相同的查询）。 我们在这里使用的所有列都有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，但假设它像其他关系数据库一样工作（除了在内存中），一个可能的原因是T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID或T_PROFILEGROUP.M_ID列上没有索引或者二进制树索引不平衡。

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

在具有大数据的表中，我遇到了不平衡的二叉树索引，导致问题，因为树的一侧远远大于其他树。 在这种情况下，重建索引可以重新平衡树。

我不能诚实地说，这是否适用于从未使用它的TimesTen，我的网络搜索没有产生太多信息。

Answer 2

我对TimesTen数据库不太熟悉，但由于它不到1/10秒，这可能只是两个查询中的四舍五入的差异还是某种打嗝？

这是一个关于性能调整TimesTen数据库的一些方法的链接 。 它有一些一般信息（使用准备等）以及有关调整特定查询的信息。 我希望它有所帮助。

Answer 3

我的粗略赌注是，第一个查询将数据从磁盘或虚拟内存拉入实际内存，第二个查询可以利用它。

你可以用三个（或十个？）查询运行它并报告回来吗？