Слишком длинное время запроса MySQL в таблице данных с датчиками

Question

У меня есть очень простая таблица для регистрации показаний с датчиков.Есть столбец для номера идентификатора датчика, один для чтения датчика и один для отметки времени.Этот столбец имеет отметку времени типа SQL.В таблице содержится большой объем данных, несколько миллионов строк.

Когда я запрашиваю все строки до определенной отметки времени с определенным номером идентификатора датчика, иногда это может занять очень много времени.Если временная метка далеко в прошлом, запрос выполняется довольно быстро, но если это недавняя временная метка, это может занять до 2 или 3 секунд.

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

В любом случае, я ищу здесь предложения по дизайну, в частности, чтобы обратиться к пунктам: почему это так медленно?и как я могу сделать это быстрее?

Есть ли здесь какая-то методика проектирования?Я не очень разбираюсь в SQL, возможно, есть способ сообщить движку SQL, что данные упорядочены (сейчас это не так, но я мог бы упорядочить их при вставке, я думаю) и ускорить запрос.Возможно, мне следует изменить способ выполнения запроса или изменить тип данных столбца отметки времени.

Answer 1

Используйте EXPLAIN, чтобы увидеть план выполнения и убедиться, что запрос использует подходящий индекс. Если нет, убедитесь, что доступны соответствующие индексы.

INDEX хранится «по порядку», и MySQL может эффективно использоваться с некоторыми шаблонами запросов. (Таблица InnoDB также хранится по порядку, ключом кластера, который является ПЕРВИЧНЫМ КЛЮЧОМ таблицы (если он существует) или первым КЛЮЧОМ UNIQUE в столбцах, отличных от NULL.)

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

EDIT

В: Почему это так медленно?

A: Есть несколько факторов, которые влияют на прошедшее время. Это может быть конфликт, например, исключительная блокировка таблицы, выполненная другим сеансом, или это может быть время для ввода-вывода (чтения с диска) или большая операция «Использование сортировки файлов». Время для возврата набора результатов по медленному сетевому соединению.

Невозможно диагностировать проблему с помощью предоставленной ограниченной информации. Мы можем предоставить только некоторые предложения по некоторым общим вопросам.

В: Как я могу сделать это быстрее?

A: Невозможно дать конкретную рекомендацию. Нам нужно выяснить, где и что является узким местом, и адрес, который.

Посмотрите на вывод из EXPLAIN, чтобы изучить план выполнения. Используется ли соответствующий индекс или выполняется полное сканирование? Сколько строк проверяется? Есть ли операция «Использование сортировки файлов»? и др.

В: Есть ли здесь какая-то методика проектирования?

A: В общем, наличие подходящего индекса и тщательная обработка оператора SQL для обеспечения максимально эффективного плана доступа.

Q: Может быть, я должен изменить способ выполнения запроса

A: Изменение оператора SQL может повысить производительность, с чего можно начать, посмотрев на план выполнения ... Можно ли изменить запрос, чтобы получить более эффективный план?

Q: или измените тип данных столбца отметки времени.

A: Я думаю, что очень маловероятно, что изменение типа данных столбца TIMESTAMP повысит производительность. Это всего 4 байта. Что бы вы изменили? Использование DATETIME заняло бы 7 байтов.

В общем, мы хотим, чтобы строки были как можно короче и упаковывать как можно больше строк в блок. Также желательно, чтобы таблица была физически организована таким образом, чтобы запросы могли быть выполнены из меньшего количества блоков ... строк, которые нужны для запроса, находятся на меньшем количестве страниц, а не строк, разбросанных по одному-большому количеству страниц на большом количестве страниц.

При использовании InnoDB увеличение размера буферного пула может уменьшить количество операций ввода-вывода.

И ввод-вывод с твердотельных накопителей (SSD) будет быстрее, чем ввод-вывод с вращающихся жестких дисков (HDD), и это особенно верно, если существует конфликт ввода-вывода на жестком диске из-за других процессов.