SQL查询性能优化（TimesTen）

问题描述：

我需要一些关于TimesTen DB查询优化的帮助。我用Java分析器做了一些测量，发现大部分时间需要的代码部分（这段代码执行SQL查询）。奇怪的是，这个查询只对一些特定的输入数据变得昂贵。SQL查询性能优化（TimesTen）

下面是这个例子。我们有两个查询表，一个表示我们想要获取的对象（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;

这是清楚地表明第一个查询花费了近100ms，而第二个查询则立即执行。这不是关于查询预编译（第一个也是预编译的，因为之前发生过相同的查询）。我们在此使用的所有列都有DB索引：T_PROFILEGROUP.M_ID,T_PROFILECONTEXT_PROFILEGROUPS.M_ID_OID和T_PROFILECONTEXT_PROFILEGROUPS.M_ID_EID。

我的问题是：

为什么查询同一套表产生不同的参数，不同的表现？
这里涉及哪些指标？
有什么办法可以改善这个简单的查询和/或数据库，使其更快？

UPDATE：给大小的感觉：

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

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

答

我不是太熟悉的TimesTen数据库，但因为它是第二这儿不到1/10，这样可以只是两个查询中的舍入差异或某种呃逆？

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

当然不是。我对执行此查询的Java代码进行了数千次的简档分析，而且显然会导致性能瓶颈，只会导致通过此连接返回多行的ID。 – 2010-06-01 14:55:34

答

我最初的疑问是，第一个查询从磁盘或虚拟内存中将数据提取到实际的内存中，第二个查询可以利用它。

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

答

我不熟悉的TimesTen但假设它像其它关系DB的（除了在存储器是），一个可能的原因是要么不存在对T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID一个索引或T_PROFILEGROUP.M_ID列或二进制的树索引不平衡。

如果没有索引，结果将取决于数据的顺序以及它能够多快地找到它们。

在拥有大量数据的表中，我经历过不平衡的二叉树索引，造成问题，因为树的一端远大于其他端。在这种情况下，重建索引可以重新平衡树。

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

SQL查询性能优化（TimesTen）

相关推荐