Как сделать этот MySQL выбор списка запросов быстрее? - PullRequest
0 голосов
/ 25 мая 2018

У меня есть следующий запрос MySQL, который мой веб-сервер выполняет с использованием SQL Alchemy ORM

(db_session.query(self.orm_model.time,
                  self.orm_model.temperature,
                  self.orm_model.fan_speed)
           .filter(self.orm_model.cook_session_id == model.cook_session_id))

Моя таблица данных о температуре выглядит следующим образом

CREATE TABLE `smoker_temp` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `cook_session_id` varchar(255) NOT NULL,
  `time` bigint(20) unsigned NOT NULL,
  `temperature` int(11) NOT NULL,
  `status_code` varchar(45) DEFAULT 'AA',
  `fan_speed` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `cook_session_id` (`cook_session_id`),
  KEY `time` (`time`)
) ENGINE=InnoDB AUTO_INCREMENT=4215274 DEFAULT CHARSET=latin1;

Когда я запускаю нагрузочный тест на моемвеб-сервер, этот запрос, кажется, длится дольше всего (т.е. кажется, что это узкое место).Данные о температуре поступают в секунду от многих пользователей, поэтому запрос выбора возвращает все более длинный список.Кроме того, операции записи выполняются на другом узле.Вышеуказанный запрос выбора выполняется реже, чем вставка.Запросы накапливаются, загрузка ЦП продолжает расти (как HTTP, так и база данных), и в итоге некоторые HTTP-запросы сбрасываются.

У меня настроена база данных на AWS RDS, и я выполняю запросы на выборку на узле только для чтения, которыйотдельно от узла записи.В моем понимании, AWS RDS будет копировать новые данные на узле только для чтения через равные промежутки времени, с которого я выполняю эти запросы выбора.

Есть ли способ сократить время выполнения этого запроса, не только с точки зрения SQLно приветствуются и другие решения, такие как изменение механизма обработки базы данных, использование базы данных, отличной от mysql, добавление / изменение индексов, изменение инфраструктуры AWS, использование ORM, отличного от SQLAlchemy, кэширование, хранимые процедуры и т. д.

Очевидное решение будетдобавить больше узлов только для чтения, но это, кажется, только задерживает возможные запросы, отбрасываемые и не устраняет узкое место

...