Эффективный запрос

использование EXPLAIN чтобы увидеть план выполнения запроса.

Для этого первого запроса MySQL не может эффективно использовать операцию сканирования диапазона индекса. Это выражение в WHERE пункт должен быть оценен для каждый строка в таблице. Мы получаем лучшую производительность, когда мы делаем сравнение с голый колонка. Сделайте манипуляцию на буквальной стороне … конвертируйте эти значения в тип данных столбца, с которым вы сравниваете.

WHERE e.date BETWEEN expr1 AND expr2

За expr1, вам нужно выражение, которое преобразует ваши $min значение в дату и время. Просто будьте осторожны с преобразованием часовых поясов. Я думаю, что это может сделать то, что вам нужно для expr1:

 FROM_UNIXTIME( $min /1000)

Что-то вроде:

WHERE e.date BETWEEN FROM_UNIXTIME( $min /1000) AND FROM_UNIXTIME( $max /1000)

Тогда мы увидим, что MySQL может эффективно использовать индекс с ведущим столбцом даты. Вывод EXPLAIN должен показать range для типа доступа.

Если количество возвращаемых столбцов является небольшим подмножеством, рассмотрим индекс покрытия. Затем EXPLAIN покажет «Использование индекса», что означает, что запрос может быть полностью выполнен из индекса, без поиска страниц в базовой таблице.

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

ЕСЛИ examID колонка в exam является уникальным и не нулевым (или его ПЕРВИЧНЫЙ КЛЮЧ examтогда, похоже, вы могли бы использовать один запрос, например так:

SELECT UNIX_TIMESTAMP(e.date)*1000 AS `date_ts`
, e.examID                    AS `examID`
, SUM(ct.ctdivol_mGy)         AS `SUM(ctdivol_mGy)`
, COUNT(ct.ctdivol_mGy)       AS `count(ctdivol_mGy)`
FROM exam e
LEFT
JOIN ct
ON ct.examid = e.examID
AND ct.ctdivol_mGy > 0
WHERE e.modality = 'CT'
AND e.date >= FROM_UNIXTIME(  $min  /1000)
AND e.date <= FROM_UNIXTIME(  $max  /1000)
GROUP
BY e.modality
, e.date
, e.examID
ORDER
BY e.modality
, e.date
, e.examID

Для достижения наилучшей производительности вам нужно охватить индексы:

  ... ON exam (modality, date, examID)
... ON ct (examID, ctdivol_mGy)

Мы бы хотели увидеть EXPLAIN выход; мы ожидаем, что MySQL может использовать индекс на экзамене для выполнения GROUP BY (и избегать операции «Использование файловой сортировки»), а также использовать ref операция по индексу ct,

Чтобы повторить … этот запрос требует, чтобы examID быть первичным ключом exam таблица (или, по крайней мере, гарантированно быть уникальным и ненулевым). В противном случае результат этого может отличаться от исходного кода. В отсутствие этой гарантии мы могли бы использовать либо встроенное представление, либо подзапросы в SELECT список. Но с точки зрения производительности, мы не хотим идти туда без уважительной причины.

Вот только некоторые общие идеи, а не жесткие и быстрые «это будет быстрее».