Почему SQL-запрос на MacOS (M2) исполняется медленнее, чем на shared-хостинге?

Question

[lexchz]

На виртуальном хостинге установлен MySQL 8.0, на макбуке M2 (ОЗУ 8 Гб) - MySQL 9.5.

Собственно, сам запрос:

SELECT pc2.category_id as id, COUNT(pc2.product_id) as total FROM oc_product_to_category pc JOIN oc_product_to_category pc2 ON pc.product_id = pc2.product_id JOIN oc_product p ON pc.product_id = p.product_id WHERE pc.category_id = 907 AND pc2.category_id IN (866,879,880,881,882,883,886,889,890,891,892,893,896,378,385,297,115,119,118,149,148,154,121,163,122,83,171,71,45,175,81,298,59,26,62,921) AND p.status = 1 GROUP BY pc2.category_id;

На макбуке время выполнения - 0.048s, в то время как на хостинге - 0.03s. Казалось бы, на маке запросы должны исполняться гораздо быстрее, ведь на shared-хостинге ресурсы очень урезаны и сайты работают медленно. Но почему-то на макбуке время хуже в 1.5 раз.
В чём может быть причина? Может, сервер MySQL лучше оптимизирован под LINUX? Или нужно правильно настроить my.cnf? (В данный момент его нет).

Результат EXPLAIN c макбука:

spoiler

| -> Table scan on <temporary>
    -> Aggregate using temporary table
        -> Nested loop inner join  (cost=1768 rows=5498)
            -> Nested loop inner join  (cost=506 rows=344)
                -> Filter: (p.`status` = 1)  (cost=386 rows=344)
                    -> Table scan on p  (cost=386 rows=3436)
                -> Single-row covering index lookup on pc using PRIMARY (product_id = p.product_id, category_id = 907)  (cost=0.25 rows=1)
            -> Filter: (pc2.category_id in (866,879,880,881,882,883,886,889,890,891,892,893,896,378,385,297,115,119,118,149,148,154,121,163,122,83,171,71,45,175,81,298,59,26,62,921))  (cost=0.476 rows=16)
                -> Covering index lookup on pc2 using PRIMARY (product_id = p.product_id)  (cost=0.476 rows=32)
 |

Результат EXPLAIN c phpMyAdmin хостинга (тут доступа к терминалу нет):

spoiler

Comments

[Владислав Лысков]

версии уже разные
вы уверены, что на хостинге mysql, а не мария?

[Everything_is_bad]

Пришло время узнать про explain analyze или что там у mysql, хотя конечно, это ты должен был сам сначала нагуглить, а не прибегать сюда. А так, очень странно сравнивать, ресурс про который что всё знаешь, с ресурсом про который у тебя очень мало данных.

[Ипатьев]

Everything_is_bad, explain покажет одно и то же, если руки не настолько кривые, чтобы и схемы были разные.
Иногда лучше жевать, чем отрыгивать очередное мизантропское поучение.

[Everything_is_bad]

Ипатьев, нет, explain минимум может показать разницу, иногда лучше "более лучше" жевать, чем пытаться мне что-то предъявить этим своим высером.

очередное мизантропское поучение.

я очень сильно офигел от того, что ты увидел в этом комментарии какое-то "мизантропское поучение".

[lexchz]

Everything_is_bad, Добавил результаты EXPLAIN, вроде всё в той же последовательности идёт.
По ANALYZE - таблицы на 100% совпадают (индексы и пр.)

Пока склоняюсь к варианту, что на виртуальном хостинге сервер БД намного мощнее (хотя и ограничивает ресурс для одного пользователя), а на маке всё возможностями железа ограничено.

[Everything_is_bad]

lexchz,

БД намного мощнее

внезапно, да?))

[Akina]

lexchz, EXPLAIN ANALYZE - это одна команда, а не две...

[lexchz]

Akina,

-> Table scan on <temporary>  (actual time=52.3..52.3 rows=36 loops=1)
    -> Aggregate using temporary table  (actual time=52.3..52.3 rows=36 loops=1)
        -> Nested loop inner join  (cost=1768 rows=5498) (actual time=0.0821..50.1 rows=7290 loops=1)
            -> Nested loop inner join  (cost=506 rows=344) (actual time=0.0685..19.8 rows=2920 loops=1)
                -> Filter: (p.`status` = 1)  (cost=386 rows=344) (actual time=0.045..14.4 rows=3038 loops=1)
                    -> Table scan on p  (cost=386 rows=3436) (actual time=0.0419..14 rows=3436 loops=1)
                -> Single-row covering index lookup on pc using PRIMARY (product_id = p.product_id, category_id = 907)  (cost=0.25 rows=1) (actual time=0.00152..0.00157 rows=0.961 loops=3038)
            -> Filter: (pc2.category_id in (866,879,880,881,882,883,886,889,890,891,892,893,896,378,385,297,115,119,118,149,148,154,121,163,122,83,171,71,45,175,81,298,59,26,62,921))  (cost=0.476 rows=16) (actual time=0.00247..0.01 rows=2.5 loops=2920)
                -> Covering index lookup on pc2 using PRIMARY (product_id = p.product_id)  (cost=0.476 rows=32) (actual time=0.00118..0.00704 rows=33.4 loops=2920)

Но тут очевидно, что на Join-ы уходит много времени, так что сам запрос уже некуда оптимизировать. Как вывод - надо дорабатывать структуру БД, переезд на VPS не только не решит проблему тяжёлых запросов, но и возможно увеличит их время исполнения.

Answer 1

[Ипатьев]

В чём может быть причина?

В чём угодно. Вопрос из серии "Почему Шумахер на жигулях обгоняет меня на феррари?"
Потому что железо - не главное, надо ещё уметь им пользоваться.

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

Comments

[lexchz]

Пришёл к выводу, что причина в том, что сервер БД на shared-хостинге банально мощнее моего ноута, поэтому и быстрее выполняет запрос. Чтобы на сайте не было запросов по 50 мс, надо адаптировать структуру БД.

[Ипатьев]

lexchz, Это самое простое объяснение. Которое не подкреплено никакими доказательствами. Люди с давних времён склонялись к простым объяснениям. Гром гремит? "Пришёл к выводу, что это Илья-пророк на колеснице едет". Чем не объяснение?

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

Что вы мне ответите, если я вас спрошу, чем это объяснение лучше той фантазии, которая у вас была в самом начале - "не настроен my.cnf"?

Что если вы локально зайдёте в бд под рутом, напишете в консоли
SET GLOBAL innodb_buffer_pool_size = 2G;
поработаете с базой и потом попробуете измерить снова?