Оптимизация представления MySQL с помощью подзапроса - PullRequest
Новая
       6

Оптимизация представления MySQL с помощью подзапроса

0 голосов
/ 10 февраля 2019

У меня проблемы с оптимизацией этого оператора SQL в MySQL.У меня есть две таблицы, которые заполняются независимо, поэтому время, зарегистрированное в столбце каждой таблицы, не будет одинаковым.Что мне нужно, так это отдельная таблица (представление), в которой перечислены все записи в sensor_history с информацией о текущем процессе, которая присутствовала во время измерения датчика.Если время журнала процесса отсутствовало, я могу жить с NULL в полях процесса в результирующем представлении для этой конкретной записи.

То, что у меня есть, работает, но это грубая сила и, к сожалению, неэффективно.В таблице sensor_history содержится около 500 тыс. Записей и около 20 тыс. Записей в таблице process_history.Я пытался разобраться в различных методах соединения, но у меня возникли проблемы с синтаксисом или плохие результаты.Я безуспешно пробовал некоторые онлайн-оптимизаторы, и я надеюсь, что кто-то здесь может направить меня в правильном направлении.

Для простоты я удалил связи внешнего ключа с другими таблицами.Нет никаких используемых индексов, но не стесняйтесь предлагать любые, которые могут помочь.Вот основы: 

CREATE TABLE `sensor_history` (
  `measurement_time_utc` int(11) NOT NULL,
  `sensor_id` int(11) NOT NULL,
  `sensor_measurement_x` double NOT NULL,
  `sensor_measurement_y` double NOT NULL,
  `sensor_measurement_z` double NOT NULL,
  `sensor_quality` int(11) NOT NULL
);

CREATE TABLE `process_history` (
  `log_time_utc` int(11) NOT NULL,
  `process_id` int(11) NOT NULL,
  `process_speed` double NOT NULL,
  `process_load` int(11) NOT NULL
);

CREATE VIEW `rollup` AS SELECT
    `sensor_history`.`measurement_time_utc`,
    `sensor_history`.`sensor_id`,
    `sensor_history`.`sensor_measurement_x`,
    `sensor_history`.`sensor_measurement_y`,
    `sensor_history`.`sensor_measurement_z`,
    `sensor_history`.`sensor_quality`,
    (SELECT `process_history`.`process_id` FROM `process_history` WHERE `sensor_history`.`measurement_time_utc`>=`process_history`.`log_time_utc` ORDER BY `process_history`.`log_time_utc` DESC LIMIT 1) AS `process_id`,
    (SELECT `process_history`.`process_speed` FROM `process_history` WHERE `sensor_history`.`measurement_time_utc`>=`process_history`.`log_time_utc` ORDER BY `process_history`.`log_time_utc` DESC LIMIT 1) AS `process_speed`,
    (SELECT `process_history`.`process_load` FROM `process_history` WHERE `sensor_history`.`measurement_time_utc`>=`process_history`.`log_time_utc` ORDER BY `process_history`.`log_time_utc` DESC LIMIT 1) AS `process_load`
    FROM `sensor_history`;

Как сделать более эффективный просмотр сводных данных?Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 12 февраля 2019

Пока вы пытаетесь выяснить, что на самом деле нужно Аналитикам, давайте сделаем некоторые улучшения, которые проще сделать сейчас, чем позже.

DOUBLE занимает 8 байтов и дает около 16 значащих цифр.Это огромное перерасход для каждого датчика, о котором я слышал.Рассмотрим 4-байтовый FLOAT, который дает вам около 7 значащих цифр.

(Куда я иду с этим? Захват данных «датчика» продолжает поступать, и в конечном итоге он заполняет диск, и это делает его медленнымИтак, давайте сжимаем вещи в ближайшее время.)

INT - это 4 байта и имеет диапазон +/- 2 миллиарда.Вы ожидаете, что так много датчиков?Как насчет 1-байта TINYINT UNSIGNED с диапазоном 0..255?Или `SMALLINT UNSIGNED (1 байт, диапазон 0,64 КБ)?То же самое для любых других идентификаторов.

Или ... Вам действительно нужно сохранить все данные?Может быть, суточные данные можно суммировать до почасовой минимальной, максимальной, средней и т. Д.?А данные за месяц нужны только для разрешения дня?

Нам есть что обсудить, как только ваши аналитики объяснят вам, чего хочет do .Затем вам нужно прочитать между строк, чтобы увидеть, что они будут хотеть .(Я тоже могу помочь.)

0 голосов
/ 10 февраля 2019

Представления действительно трудно оптимизировать в MySQL.Вы надеетесь на индекс: 

process_history(log_time_utc, process_id, process_speed)

Последние два столбца включены, поэтому индекс охватывает запрос и не должен ссылаться на страницы данных.

...