MySQL запрос медленнее, так как он обращается к данным ниже в таблице - PullRequest
2 голосов
/ 25 мая 2020

У меня есть MySQL БД, работающая на raspi4 2GB на USB> SATA SSD с интерфейсом разъема python. Когда я запускаю запрос

UPDATE sessions
SET used = 1, date_created = %s, places = %s, loc_query = %s,
    resp_loc = %s, resp_json = %s, ip_address = %s, full_q_string = %s
WHERE used IS NULL
LIMIT 1

, он работает быстро (~ .1 se c), но по мере нахождения строк ниже в списке он становится намного медленнее (на 2-3 + секунды, по строкам ~ 9000 это 4-5 секунд). Я думал, что это из-за заполнения базы данных, но когда я go возвращаюсь и освобождаю строки 1-10 с помощью NULLING всех заполненных столбцов в запросе и установки «used» = NULL, эти первые 10 строк молниеносно работают даже с остальные 9000 строк заполнены, затем, когда он начинает запись в строку 9001, он снова становится медленным. Я попытался написать директиву для строки более высокого уровня

UPDATE sessions
     SET used = 1, date_created = %s, places = %s, loc_query = %s,
         resp_loc = %s, resp_json = %s, ip_address = %s, full_q_string = %s
    WHERE placeholder_id = 9002` 

Он работает хорошо / быстро, но мне нужна логика / идея в первом запросе для работы. Наконец, я попытался перезапустить Pi, чтобы попытаться избавиться от sh RAM, думая, что это какая-то кеширующая штука, но срок ее действия такой же. Любые советы по вводу будут приложены :)

MySQL - (mysql Ver 8.0.20-0ubuntu0.20.04.1 для Linux на aarch64 ((Ubuntu)))

Столбцы таблицы:

                         placeholder_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
                         session_key CHAR(5),
                         date_polled DATETIME,
                         date_created DATETIME(6),
                         full_q_string VARCHAR(2550),
                         ip_address VARCHAR(255),
                         places JSON,
                         loc_query LONGTEXT,
                         resp_loc LONGTEXT,
                         resp_json JSON

1 Ответ

3 голосов
/ 25 мая 2020

Проблема в том, что MySQL имеет строку, где user IS NULL. Это может занять больше времени.

Решение состоит в том, чтобы создать индекс для user:

create index idx_sessions_user on sessions(user);

MySQL должен иметь возможность использовать индекс для поиска NULL row довольно быстро ускоряет ваши обновления (с небольшими накладными расходами на поддержание индекса на insert s и update s).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...