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数据库的方法。它具有一些一般信息(使用准备等)以及有关调整特定查询的信息。我希望它有帮助。
我最初的疑问是,第一个查询从磁盘或虚拟内存中将数据提取到实际的内存中,第二个查询可以利用它。
你可以用三个(或十个?)查询运行这个查询并回报吗?
我不熟悉的TimesTen但假设它像其它关系DB的(除了在存储器是),一个可能的原因是要么不存在对T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID一个索引或T_PROFILEGROUP.M_ID列或二进制的树索引不平衡。
如果没有索引,结果将取决于数据的顺序以及它能够多快地找到它们。
在拥有大量数据的表中,我经历过不平衡的二叉树索引,造成问题,因为树的一端远大于其他端。在这种情况下,重建索引可以重新平衡树。
我不能诚实地说,如果这适用于TimesTen从未使用它,我的网络搜索不产生太多的信息。
当然不是。我对执行此查询的Java代码进行了数千次的简档分析,而且显然会导致性能瓶颈,只会导致通过此连接返回多行的ID。 – 2010-06-01 14:55:34