У меня есть следующие таблицы в MySQL:группы MySQL по запросу с оптимизацией подвыборки
CREATE TABLE `events` (
`pv_name` varchar(60) COLLATE utf8mb4_unicode_ci NOT NULL,
`time_stamp` bigint(20) unsigned NOT NULL,
`event_type` varchar(40) COLLATE utf8mb4_unicode_ci NOT NULL,
`value` text CHARACTER SET utf8mb4 COLLATE utf8mb4_bin,
`value_type` varchar(40) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`value_count` bigint(20) DEFAULT NULL,
`alarm_status` varchar(40) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`alarm_severity` varchar(40) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`pv_name`,`time_stamp`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=COMPRESSED;
CREATE TEMPORARY TABLE `matching_pv_names` (
`pv_name` varchar(60) NOT NULL,
PRIMARY KEY (`pv_name`)
) ENGINE=Memory DEFAULT CHARSET=latin1;
Таблица matching_pv_names
содержит подмножество уникальных events.pv_name
значений.
Следующий запрос выполняется с помощью «свободного индекса сканирования» оптимизации:
SELECT events.pv_name, MAX(events.time_stamp) AS time_stamp
FROM events
WHERE events.time_stamp <= time_stamp_in
GROUP BY events.pv_name;
Можно ли улучшить время этого запроса, ограничивая events.pv_name
значения для тех, кто в matching_pv_names
таблицы не теряя «свободно оптимизация индекса?
что-то странное. Откуда находится поле «time_stamp_in»? – Kordi
time_stamp_in скорее всего является входным значением. –
time_stamp_in - переменная, переданная в хранимую процедуру, в которой выполняется запрос. – Patrick