Оптимизация производительности SQL-запросов (TimesTen) - PullRequest
Новая
       21

Оптимизация производительности SQL-запросов (TimesTen)

3 голосов
/ 01 июня 2010

Мне нужна помощь с оптимизацией запросов к базе данных TimesTen. Я предпринял некоторые меры с помощью профилировщика Java и нашел раздел кода, который занимает большую часть времени (этот раздел кода выполняет запрос SQL). Что странно, что этот запрос становится дорогим только для некоторых конкретных входных данных.

Вот пример. У нас есть две таблицы, которые мы запрашиваем, одна представляет объекты, которые мы хотим получить (T_PROFILEGROUP), другая представляет ссылку «многие ко многим» из другой таблицы (T_PROFILECONTEXT_PROFILEGROUPS). Мы не запрашиваем связанную таблицу.

Это запросы, которые я выполнил при запущенном профилировщике БД (они идентичны, кроме идентификатора): 

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 мс, а второй был выполнен мгновенно. Речь идет не о прекомпиляции запросов (первый тоже прекомпилируется, как и те же запросы, что и раньше). У нас есть индексы БД для всех используемых здесь столбцов: 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.

Ответы [ 3 ]

1 голос
/ 01 декабря 2011

Я не знаком с TimesTen, но, если предположить, что он работает как другие реляционные БД (за исключением того, что находится в памяти), одной из возможных причин является либо отсутствие индекса для столбцов T_PROFILECONTEXT_PROFILEGROUP.M_ID_OID, либо T_PROFILEGROUP.M_ID, либо двоичное дерево Индекс не сбалансирован.

Без индекса результаты будут зависеть от порядка данных относительно того, как быстро они их найдут.

В таблицах с большими данными я столкнулся с несбалансированными двоичными индексами дерева, вызывающими проблемы, поскольку одна сторона дерева намного больше, чем другие. В этом случае перестроение индекса может перебалансировать дерево.

Я не могу честно сказать, применимо ли это к TimesTen, который никогда не использовал его, и мои поисковые запросы в Интернете не дают много информации.

0 голосов
/ 27 августа 2010

Моя грубая ставка заключается в том, что первый запрос извлекает данные с диска или виртуальной памяти в реальную память, а второй запрос получает преимущество.

Можете ли вы выполнить это с тремя (или десятью) запросами и отчитаться?

0 голосов
/ 01 июня 2010

Я не слишком знаком с базой данных TimesTen, но так как здесь меньше 1/10 секунды, может ли это быть просто разница в округлении в двух запросах или какой-то сбой?

Вот ссылка , которая описывает некоторые методы настройки производительности базы данных TimesTen. Он содержит некоторую общую информацию (с использованием подготовок и т. Д.), А также информацию о настройке конкретных запросов. Надеюсь, это поможет.

...