Forum d'entraide PHPFrance

Bonjour à tous, j’ai besoin d’avis SVP.

Dans un projet, Cette req SQL me "sature" le CPU de mon VPS (c’est un petit VPS 1 cœurs et 2 Go de RAM).

select
    `orders_super_parents`.`id`,
    `orders`.`id` as `order_lastUpdatedAt_id`,
    `orders_dates`.`date_for_stats_filter` as `orderDate__date_for_stats_filter`
from `orders_super_parents`
inner join `orders` 
    on `orders_super_parents`.`order_id_last_updated_at` = `orders`.`id`
inner join `orders_dates` on `orders`.`id` = `orders_dates`.`order_id`
where `orders_super_parents`.`deleted_at` is null
order by `orders_super_parents`.`row_number` desc
limit 15 offset 0

Technos que j’utilise : PHP 8.0 / Laravel 8 / MariaDB 10.6.

Par contre quand je remplace la ligne orders_dates.date_for_stats_filter as orderDate__date_for_stats_filter (qui est une colonne de type timestamp) par orders_dates.id as orderDate__date_for_stats_filter (qui est un simple id integer), tout fonctionne rapidement nickel (ma req SQL se traite en 0.0024 secondes au lieu de 0.5950 secondes, je le vois quand je débogue PhpmMyAdmin).

C’est la première fois que je vois une req SQL "saturer" un de mes VPS car je select un champs de type timestamp.

Pour essayer de debugger, j'ai executé ces 2 req SQL avec EXPLAIN (j’ai fais des impr écran) :

Avec la colonne timestamp orders_dates.date_for_stats_filter (la req SQL qui rame) :


Avec la colonne integer orders_dates.id :


Un avis SVP ?

Merci.

Bonjour,

Pas assez compétent en sql pour confirmer que c'est bien le problème, mais à priori la lenteur d'exécution de la requête pourrait venir d'un index manquant (le type ALL, les keys NULL et le Extra "Using where; Using join buffer" dans le retour du EXPLAIN de la première requête semble confirmer cela).
https://blog.seboss666.info/2015/11/uti ... uetes-sql/