Здравствуйте
Столкнулся с такой проблемой есть программа офлайн читалка сайта RSDN Janus,
так при ( назвать это длительной работой язык не поворачиваеться 2 месяца,
скажу так :) ) накоплении некоторого количества информации ~ 47000 записей,
синхронизация и вставка новых данных начинает жутко тормозить, вернее
начинает она намного раньше. При исследовании использовал
http://csmon.narod.ru/ Матвеева Олега и с его помощью выловил(хотя хотя
монитор не для этого, но будем считать что мне повезло :) )запрос который
тормозит. Сделал тест:
SET SQL DIALECT 3;
SET NAMES NONE;
CREATE TABLE NEW_TABLE (
A INTEGER NOT NULL
);
ALTER TABLE NEW_TABLE ADD CONSTRAINT PK_NEW_TABLE PRIMARY KEY (A);
Вставил 5000 записей датагенератором експерта. Данные в диапазоне 1 - 5000.
Подзапрос заведомо возвращает NULL.
запрос и статистика по нему
SELECT a FROM NEW_TABLE nt
WHERE nt.a
IN
(
SELECT Min(nt.a)
FROM NEW_TABLE nt
WHERE nt.a IN
(2590757,2585395,2581973,2587496,2588517,2590089,2591285,2591989,2589558,2591954,2591660,
2584218,2592173,2591075,2591967,2592027,2591746,2578513,2591458,2589385,2592092,2566489,2591808,2592129,
2592249,2590312,2592260,2566933,2589299,2592270,2590330,2584950,2591864,2591074,2569898,2591063,2591602,
2592319,2587715,2586965,2592346,2586209,2590264,2592274,2592282,2592288,2592186,2592390,2591001,2587252,
2584688,2592443,2592482,2592488,2591155,2587254,2592505,2592520,663451,2592539,2583152,2592569,2590770,
2592591,2591490,2591326,2591782,2592705,2587841,2592729,2592730,2592749,2592753,2587155,2592802,2592811,
2562379,2585485,2586999,2592843,2592856,2590461,2592878,2591826,2589560,2592927,2589275,2031510,2592959,
2592960,2592968,2518100,2586433,2592995,2588381,2450394,2579061,2579077,2517534,2590922,2586977,2419463,
2591493,2593091,2575595,2576436,2590781,2575958,2551106,2583199,2572646,2581681,2593192,2593197,2590956,
2593208,2593218,2593219,2591828,2593233,2593235,2443637,2593238,2590228,2423876,2593253,2593266,2549182,
2593120,2583703,2593332,1800649,2593375,2593386,2593418,2580984,2593443,2583654,2579442,2593502,2544192,
2593512,2581698,2593535,2587716,2586005,2581088,2588494,2467590,2593621,2593631,2593669,2552383,2593672,
2593689,2593704,2593713,2591554,2593747,2593748,2315565,2571906,2593778,2593792,2593796,2513627,2593873,
2580065,2593941,2593982,2593993,2593996,2587464,2567951,2583486,2585719,2585656,2586473)
)
------ Performance info ------
Prepare time = 31ms
Execute time = 17s 594ms
Current memory = 2 774 024
Max memory = 2 905 948
Memory buffers = 90
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 2 700 037
Не индексированных чтений 5000.
При увеличении данных до 10000 записей время выполнения этого-же запроса
возрастает и статистика выглядит так:
------ Performance info ------
Prepare time = 31ms
Execute time = 52s 281ms
Current memory = 2 774 076
Max memory = 3 090 284
Memory buffers = 90
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 5 410 067
Не индексированных чтений соответственно 10000.
Хотя по отдельности запросы отрабатываються в пределах 10 ms и с планом
выполнения.
Мне кажеться что при выполнении запроса сначала разворачиваеться in, а потом
выполняеться подзапрос, может правильнее было-бы выполнить подзапрос, а
потом результаты развернуть в in ?
Или я не правильно понимаю "политику партии"?
