Тоже давно заметил, что в фоне запущена служба Я.Метро, даже если приложение выключено. Пришлось снести приложение, хотя бы в целях экономии ресурсов телефона.
Обнаружил в базе один из моих email, почта не основная, была зарегана на всякий случай пару лет назад. Использовался только для пересылки почты на gmail, больше нигде пароль не вводил.
Так что ввод пароля на левом сайте исключаю.
Добавлю еще использование индексов на временных (сессионных) таблицах в ORACLE бессмысленно. Индекс можно создать, но статистика по нему не будет собираться, значит оптимизатор его не будет использовать.
Есть вариант подсунуть статистику от аналогичной не временной таблицы, но это как то уж больно запарно.
Проблему можно решить, прибегая к временным таблицам, т.е. результат тяжелого запроса предварительно положить во временную таблицу и далее использовать.
Кстати, ORACLE, в данном случае, чаще всего сам создает временную таблицу, ну или ему можно подсказать хинтом /*+ materialize */ и преимущество использования WITH будет очевидно.
Да, кеш не сбрасывал. Индексы создавал, как в статье написано, чтобы не было разночтений.
По вашим замерам все равно получается, что обычный hash join лучше аналитической функции.
CREATE TABLE tmp_shop (
id INTEGER,
article INTEGER NOT NULL,
dealer VARCHAR(45) NOT NULL,
price NUMBER(8,2) NOT NULL,
constraint PK_tmp_shop primary key (ID) using index tablespace IDX
) TABLESPACE DAT;
INSERT INTO tmp_shop (id, article, dealer, price)
SELECT rownum, CEIL(dbms_random.value(8,2) * 9999), CEIL(dbms_random.value(8,2) * 999), dbms_random.value(8,2) * 9999
FROM dual
connect by level < 1000000;
create index i_tmp_shop_FND on tmp_shop (article asc) tablespace IDX;
--=0.848
SELECT article, dealer, price
FROM tmp_shop s1
WHERE price=(SELECT MAX(s2.price)
FROM tmp_shop s2
WHERE s1.article = s2.article);
DROP index i_tmp_shop_FND;
create index i_tmp_shop_FND on tmp_shop (article, price) tablespace IDX;
--0.502
SELECT s1.article, dealer, s1.price
FROM tmp_shop s1
JOIN (
SELECT article, MAX(price) AS price
FROM tmp_shop
GROUP BY article
) s2 ON s1.article = s2.article AND s1.price = s2.price;
--4.38
select article, dealer, price
from (
select s.*, row_number() over (partition by article order by price desc) as r
from tmp_shop s) s1
where r = 1;
--2.1
select article, MAX(dealer) KEEP(DENSE_RANK FIRST ORDER BY price DESC), MAX(price)
FROM tmp_shop
GROUP BY article
Так что ввод пароля на левом сайте исключаю.
Есть вариант подсунуть статистику от аналогичной не временной таблицы, но это как то уж больно запарно.
Кстати, ORACLE, в данном случае, чаще всего сам создает временную таблицу, ну или ему можно подсказать хинтом /*+ materialize */ и преимущество использования WITH будет очевидно.
Mysql в этом плане гораздо удобней.
Насчет оптимизации не знаю, нет возможности сейчас проверить план.
Время без индексов: 4.4с (стоимость 5753 — фулскан таблицы ), с индексом: 0,044с (стоимость 3915 — фулскан индекса ). Таблицу между вариантами пересоздавал.
У первого и второго запроса с одинаковыми индексом от 3 варианта одинаковая стоимость и время выполнения 0,5с.
Так что, похоже, 3ий вариант самый быстрый.
По вашим замерам все равно получается, что обычный hash join лучше аналитической функции.
Тут пригодились бы KEEP или OVER.
Ну и демо: cash.pihel.jino.ru/?act=analiz