|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток!
Запрос имеет вид -
select
c.servicecall,
c.id,
d.WOG_NAME,
d.DEPAR_NAME,
c.created,
c.status,
c.`assigner`,
c.actual_start,
c.timestampAdd,
c.regl
from
(select a.servicecall, a.id, a.created, a.status, a.`assigner`, a.workgroup_oid, a.actual_start, a.timestampAdd, (UNIX_TIMESTAMP(now()) - UNIX_TIMESTAMP(a.timestampAdd)) as regl
from
(select t.servicecall, t.id, t.created, t.`status`, t.workgroup_oid, t.actual_start, t.`assigner`, t.timestampAdd from bo.ordersBO t
where t.timestampAdd >= DATE_SUB(CURRENT_DATE, INTERVAL 4 DAY) AND t.`status` IN ('Новый', 'В работе')) a
LEFT JOIN
(select t.servicecall, t.`status` from bo.ordersBO t
where t.timestampAdd >= DATE_SUB(CURRENT_DATE, INTERVAL 4 DAY) AND t.`status` = 'Закрыто') b
on a.servicecall = b.servicecall where b.`status` is null) c
JOIN
bo.spr_orders_binding d
on c.workgroup_oid = d.NAME_ID WHERE c.regl >=86400 order by c.`servicecall`
Всё работает, но сам запрос выполняется более 300!!! сек.! Индексы построены по полям servicecall, id, workgroup_oid, timestampAdd, status... Подскажите - как можно ускорить выборку?
Заранее спасибо за помощь!
Неактивен
покажите план запроса и структуру таблиц
Неактивен
Поскольку не на работе сейчас, то вкратце план такой - отбор всех записей, которые подпадают под условие В РАБОТЕ, НОВЫЙ, в интервале времени от текущей даты минус 4 суток. Отбрасываем, через JOIN, те записи, которые со статусом ЗАКРЫТО. Далее высчитываю разницу между текущей датой и датой начала статуса В РАБОТЕ или НОВЫЙ и после этого сравниваю со справочником и вывожу только те записи, которые принадлежат моему отделу. Таблиц две - первая ordersBO боевая, а spr_orders_binding - это справочник (124 строки)
Как-то так...
Неактивен
навскидку у вас лишний from подзапрос.
Неактивен
Здравствуйте! Частично помогло то, что Вы посоветовали... Я пробовал скомбинировать по разному, но время выборки лишь удалось уменьшить до 150 сек., меньше никак... Понятно, что при увеличении интервала дней (INTERVAL 4 DAY) и время итогового вывода увеличивается... В принципе - такое всё-же устраивает, потому что это уже не 300 сек. 
Спасибо за помощь!!!
Неактивен
150 секунд это тоже много.
Сколько у вас всего записей за 4 дня, сколько отбираются подзапросами? Ну и план (explain select ..) со структурой таблиц (show create ..) покажите.
Неактивен
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> ALL 1117 Using where; Using filesort
1 PRIMARY d ref NAME_ID NAME_ID 9 c.workgroup_oid 1 Using where
2 DERIVED <derived3> ALL 13466
2 DERIVED <derived4> ALL 5907 Using where
4 DERIVED t ref timestampAdd,status status 63 39468 Using where
3 DERIVED t range timestampAdd,status timestampAdd 9 20281 Using where
**********************************************************************************************
Table Create Table
ordersBO CREATE TABLE `ordersBO` (
`servicecall` bigint(15) DEFAULT NULL,
`sc_classification` bigint(20) DEFAULT NULL,
`parent_id` bigint(15) DEFAULT NULL,
`id` bigint(15) DEFAULT NULL,
`oid` bigint(20) DEFAULT NULL,
`classification` bigint(20) DEFAULT NULL,
`complexity` bigint(5) DEFAULT NULL,
`description` varchar(250) DEFAULT NULL,
`created` varchar(20) DEFAULT NULL,
`requestor` varchar(20) DEFAULT NULL,
`info` text,
`status` varchar(20) DEFAULT NULL,
`workgroup` varchar(250) DEFAULT NULL,
`workgroup_oid` bigint(20) DEFAULT NULL,
`assigner` varchar(20) DEFAULT NULL,
`actual_start` varchar(20) DEFAULT NULL,
`solution` text,
`remark` text,
`actual_finish` varchar(20) DEFAULT NULL,
`closecode` varchar(20) DEFAULT NULL,
`score` bigint(5) DEFAULT NULL,
`timestamp` bigint(20) DEFAULT NULL,
`dateAdd` date NOT NULL,
`timestampAdd` datetime DEFAULT NULL,
KEY `workgroup_oid` (`workgroup_oid`),
KEY `timestampAdd` (`timestampAdd`),
KEY `id` (`id`),
KEY `status` (`status`),
KEY `servicecall` (`servicecall`),
KEY `closecode` (`closecode`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Данные по ордерам HelpDesk'
Неактивен
А если так?
Неактивен
Ув. Архат (vasya), ерунда какая-то, но выигрыша в скорости не больше 10% 
Я в шоке... Единственное подозрение - сервер! Он в самом деле чрезвычайно медленный, сделан на Atom... Обычные select работают так-сяк, а вот когда дело касается двух-трёх JOIN, а если при этом происходит ещё какой-то insert OR update, вообще всё ложится... Так что наверное дело не в выборке... ИМХО!
Неактивен
Число транзисторов в процессоре Atom сокращено за счет блока для вычислений с плавающей точкой. Однако, целочисленные операции он выполняет достаточно быстро, поэтому трудно сказать дело в нем или нет.
Неактивен
