Страница 1 из 1
Перенес запрос в ХП, скорость упала. Индексы.
Добавлено: 13 фев 2007, 09:53
Leshgan
В клмиентском приложении был запрос:
Код: Выделить всё
select main_base.nom_doc, main_base.name_cl, main_base.date_zay,
main_base.nac, main_base.nac_k, main_base.prim, base.name_tv, base.izgot, base.cena,
base.cena_k, base.kol_zav, base.kol_zak from MAIN_BASE, base
where base.nom_doc=68000 and main_base.nom_doc=68000
order by base.name_tv
Переделал в ХП:
Код: Выделить всё
CREATE PROCEDURE SP_PRINTZAY (
TEMP_NOM_DOC INTEGER)
RETURNS (
NOM_DOC INTEGER,
NAME_CL VARCHAR(50),
DATE_ZAY DATE,
NAC NUMERIC(15,2),
NAC_K NUMERIC(15,2),
PRIM VARCHAR(50),
NAME_TV VARCHAR(50),
IZGOT VARCHAR(40),
CENA NUMERIC(15,2),
CENA_K NUMERIC(15,2),
KOL_ZAK INTEGER,
KOL_ZAV INTEGER)
AS
begin
for
select main_base.nom_doc, main_base.name_cl, main_base.date_zay,
main_base.nac, main_base.nac_k, main_base.prim,
base.name_tv, base.izgot, base.cena, base.cena_k, base.kol_zak,
base.kol_zav from main_base, base
where main_base.nom_doc= :temp_nom_doc and base.nom_doc = :temp_nom_doc
into :nom_doc, :name_cl, :date_zay, :nac, :nac_k, :prim, :name_tv,
:izgot, :cena, :cena_k, :kol_zak, :kol_zav
do
begin
suspend;
end
Прошу прощения если кода слишком много, можно и не вникать во все поля таблиц, просто скажу, что по базе main_base был индекс по полю nom_doc, сделал в таблице base индекс по полю nom_doc, запрос стал работать мгновенно. Но в хранимой процедуре анализ плана показывает, что идут неиндексированные чтения. Оно-то, в принципе, понятно, но как ускорить выполнение такой ХП?
Добавлено: 13 фев 2007, 10:22
CyberMax
Вот за это:
Код: Выделить всё
from MAIN_BASE, base
where base.nom_doc=68000 and main_base.nom_doc=68000
надо по рукам бить.
Срочно изучать
http://www.ibase.ru/devinfo/joins.htm.
Добавлено: 13 фев 2007, 10:23
kdv
да что ж вы так боитесь этих "неиндексированных чтений"...
собственно, я не пойму, в чем вопрос. Запрос отдельно и внутри процедуры одинаковый? План дает одинаковый? Дисконнект после создания индекса (для выгрузки процедуры из кэша метаданных) делал?
Добавлено: 13 фев 2007, 11:27
Leshgan
Да, я в join пока не секу, признаюсь. Повлияет ли на скорость если через join сделаю? Цифра 68000, естественно, была приведена в кач-ве примера.
kdv писал(а):
Запрос отдельно и внутри процедуры одинаковый? План дает одинаковый? Дисконнект после создания индекса (для выгрузки процедуры из кэша метаданных) делал?
Запрос одинаковый, план НЕ одинаковый! В запросе используются индексы по таблице main_base (nom_doc), по таблице base (nom_doc). В ХП план показывает, что по таблице base ничего не используется. Дисконнект не делал срзу, сейчас сделал. ХП стала быстрее отрабатывать, но до простого запроса далеко. Получается смысл делать ХП если запрос быстрее отработает?
Добавлено: 13 фев 2007, 11:53
CyberMax
Leshgan писал(а):Да, я в join пока не секу, признаюсь. Повлияет ли на скорость если через join сделаю? Цифра 68000, естественно, была приведена в кач-ве примера.
Сложно сказать. Надо планы смотреть по обоим случаям.
Leshgan писал(а):Получается смысл делать ХП если запрос быстрее отработает?
А зачем тебе ХП делать, если можно запросом обойтись? Или того требуют бизнес-правила?
Давай планы по запросу и по ХП, статистику по выполнению и версию сервера.
Добавлено: 13 фев 2007, 11:57
WildSery
Один и тот же запрос что сам по себе, что в ХП отрабатывает одинаково.
ХП делают не для того, чтобы тот же самый запрос "ускорить", а чтобы сделать вещи, недоступные для простого селекта, или же для исключения бизнес-логики из клиентской части.
Запросы у тебя разные - в ХП нет ORDER BY. Отсюда разные планы.
Читай JOINS, как посоветовали.
Добавлено: 13 фев 2007, 12:01
Leshgan
CyberMax писал(а):
А зачем тебе ХП делать, если можно запросом обойтись? Или того требуют бизнес-правила?
Давай планы по запросу и по ХП, статистику по выполнению и версию сервера.
План ХП
Код: Выделить всё
Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 3 297,00 ms
Avg fetch time: 3 297,00 ms
Memory
------------------------------------------------
Current: 18 695 565
Max : 19 605 231
Buffers: 2 048
Operations
------------------------------------------------
Read : 9 659
Writes : 1
Fetches: 1 085 157
Enchanced Info:
+--------------------------+-------+-----------+---------+---------+---------+
| Table Name | Index | Non-Index | Updates | Deletes | Inserts |
| | reads | reads | | | |
+--------------------------+-------+-----------+---------+---------+---------+
| MAIN_BASE| 23 | 0 | 0 | 0 | 0 |
| BASE| 0 | 532851 | 0 | 0 | 0 |
+--------------------------+-------+-----------+---------+---------+---------+
План запроса:
Код: Выделить всё
Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 32,00 ms
Avg fetch time: 1,39 ms
Memory
------------------------------------------------
Current: 18 696 589
Max : 19 605 231
Buffers: 2 048
Operations
------------------------------------------------
Read : 0
Writes : 0
Fetches: 57
Enchanced Info:
+--------------------------+-------+-----------+---------+---------+---------+
| Table Name | Index | Non-Index | Updates | Deletes | Inserts |
| | reads | reads | | | |
+--------------------------+-------+-----------+---------+---------+---------+
| MAIN_BASE| 1 | 0 | 0 | 0 | 0 |
| BASE| 23 | 0 | 0 | 0 | 0 |
+--------------------------+-------+-----------+---------+---------+---------+
Server Version Info
---------------------------------------------------------------------------
Server Version: WI-O6.0.2.0
Server Implementation: InterBase/x86/Windows NT
Service Version: 2
---
Но сервер будет в будущем на FB2.0
Добавлено: 13 фев 2007, 12:07
Leshgan
WildSery писал(а):
Запросы у тебя разные - в ХП нет ORDER BY. Отсюда разные планы.
Читай JOINS, как посоветовали.
Черт. А слона-то я не заметил. Спасибо! добавил order by и всё поменялось.
Всё равно ушел читать про joins.
WildSery писал(а):ХП делают не для того, чтобы тот же самый запрос "ускорить", а чтобы сделать вещи, недоступные для простого селекта, или же для исключения бизнес-логики из клиентской части.
Это я знаю, но пока я набираюсь опыта. Скажите, именно вот такие запросы не имеет смысла переносить в ХП? Логики никакой нет, я просто хотел упростить в написании клиентского приложение запросы: просто вызвал ХП с параметром номера накладной и вернул выборку. Просто некое удобство, но не выыигрыш производительности хотел добиться.
Добавлено: 13 фев 2007, 12:15
kdv
План ХП
у ХП нет плана. один и тот же запрос сам по себе и внутри процедуры будет иметь абсолютно тот же самый план.
Другое дело, как ты вызываешь процедуру. Если ты добавляешь where, order by снаружи процедуры, то это выполняется совсем по другому, чем при добавлении тех же операторов к запросу.
Добавлено: 13 фев 2007, 12:23
WildSery
Leshgan писал(а):Server Version: WI-O6.0.2.0
Признавайся, где взял?
Добавлено: 13 фев 2007, 14:20
Leshgan
kdv писал(а):
у ХП нет плана. один и тот же запрос сам по себе и внутри процедуры будет иметь абсолютно тот же самый план.
Другое дело, как ты вызываешь процедуру. Если ты добавляешь where, order by снаружи процедуры, то это выполняется совсем по другому, чем при добавлении тех же операторов к запросу.
Понял, спасибо! Вообще я всё делал в IB Expert. ХП вызывал просот с параметром и order by ему не делал
А можете сказать как лучше использовать в данном случае order by: в самой ХП прописать его или при вызове ХП из приложения?
Код: Выделить всё
select * from sp_printzay(68000) order by name_tv
WildSery писал(а):
Признавайся, где взял?
Скачено в году так 2002 с сайта Borland, если мне не изменяет память , тогда же установлено, написано приложение и с тех пор туда не лазил. Сейчас вернулся к этому делу, локально пока поставил FB2.0, на сервере всё так же стоит IB6.0
А что не так?
Добавлено: 13 фев 2007, 16:03
kdv
А что не так?
6.0.2 на борланде никогда не было.
www.ibase.ru/devinfo/allversions.htm
еще немного, и я буду запрещать здесь задавать вопросы по IB 6.0.
Добавлено: 13 фев 2007, 16:36
Leshgan
Из Вашей ссылки:
6.0.2.0 - от mers.com, иногда именуется как 6.2 - бесплатный, крайне не рекомендуется к использованию (баги)
Спасибо за ответы, вопрос исчерпан.
Добавлено: 13 фев 2007, 16:46
kdv
Из Вашей ссылки
ссылки я даю затем, чтобы не цитировать.