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

0

У меня большая база данных mysql (планируется около миллиона записей), и я хочу проверить ее производительность, создав худший запрос (самое длинное время вычисления), в котором я могу.

На данный момент это база данных с двумя таблицами:

CREATE TABLE user  (ID BIGINT NOT NULL AUTO_INCREMENT,
                    createdAt DATETIME NULL DEFAULT NULL,
                    lastAction DATETIME NULL DEFAULT NULL,
                    ip TEXT NULL DEFAULT NULL,
                    browser TEXT NULL DEFAULT NULL,
                    PRIMARY KEY (ID))

CREATE TABLE evt  (ID BIGINT AUTO_INCREMENT,
                   UID BIGINT NULL DEFAULT NULL,
                   timeStamp DATETIME NULL DEFAULT NULL,
                   name TEXT NULL DEFAULT NULL,
                   PRIMARY KEY (ID),
                   FOREIGN KEY (UID)
                   REFERENCES user(ID))

Он заполняется и работает локально, поэтому соединение не требуется.
Существуют ли какие-либо правила Thumb о том, как создавать ужасные запросы?

Мой худший запрос на данный момент:

SELECT user.browser, evt.name, count(*) as AmountOfActions
    FROM evt
    JOIN user ON evt.UID = user.ID
    GROUP BY user.browser, evt.name
    ORDER BY AmountOfActions DESC
Теги:
performance

1 ответ

1
Лучший ответ

Стоимость номер один в запросе - это хиты диска. Итак, сделайте таблицу достаточно большой, чтобы ее нельзя было кэшировать в ОЗУ. И/или выполните перекрестное соединение (и т.д.), Так что промежуточная таблица слишком велика для кэширования в ОЗУ.

Общей проблемой на этом форуме является множество объединений, за которыми следует группа. Или множество объединений, а также заказ на большой промежуточный результат.

Здесь double-whammy - объединяйте две таблицы (каждая из которых слишком велика для кэширования) на UUID.

  • 0
    Да уж. после комментария @ Uueerdo я попробовал эти уловки. Я увеличил объем памяти до 1 ГБ, и все равно мне пришлось уменьшить максимальное количество строк примерно до 4 миллионов. Присоединение evt к пользователю заняло около 8 секунд, чтобы сохранить результаты в ResultSet с JDBC. Большое спасибо за ответ!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню