mariadb slow count on console but very fast on dbeaver - mysql

Question

I have this SQL query that when executing from mariadb console or PHP (Laravel) takes a long time
SELECT Count(*) AS aggregate
FROM (SELECT paquetes.id,
paquetes.codigoseguimiento,
paquetes.direccionentrega,
paquetes.telefono1,
paquetes.nombrerecibe,
paquetes.nombrequienenvia,
paquetes.estado,
paquetes.marcadevolucion,
tipos_paquetes.nombre AS tipo,
paquetes.created_at,
paquetes.devolucion,
ciudades.nombre AS ciudadEntrega
FROM paquetes
LEFT JOIN tipos_paquetes
ON tipos_paquetes.id = paquetes.tipo
LEFT JOIN ciudades
ON ciudades.id = paquetes.ciudadentrega
WHERE paquetes.created_at BETWEEN
"2021-10-17 00:00:00" AND "2021-11-17 23:59:59"
AND paquetes.estado != 0
ORDER BY paquetes.created_at DESC) count_row_table
Result:
+-----------+
| aggregate |
+-----------+
| 763141 |
+-----------+
1 row in set (20.631 sec)
But if I run the same SQL from DBeaver (always clearing the query cache)
It only takes 1,458 seconds.
What I discovered is that adding a limit 1 to the SQL runs at the same speed as DBeaver in both mariadb console and PHP
SELECT Count(*) AS aggregate
FROM (SELECT paquetes.id,
paquetes.codigoseguimiento,
paquetes.direccionentrega,
paquetes.telefono1,
paquetes.nombrerecibe,
paquetes.nombrequienenvia,
paquetes.estado,
paquetes.marcadevolucion,
tipos_paquetes.nombre AS tipo,
paquetes.created_at,
paquetes.devolucion,
ciudades.nombre AS ciudadEntrega
FROM paquetes
LEFT JOIN tipos_paquetes
ON tipos_paquetes.id = paquetes.tipo
LEFT JOIN ciudades
ON ciudades.id = paquetes.ciudadentrega
WHERE paquetes.created_at BETWEEN
"2021-10-17 00:00:00" AND "2021-11-17 23:59:59"
AND paquetes.estado != 0
ORDER BY paquetes.created_at DESC) count_row_table
LIMIT 1;
Result:
+-----------+
| aggregate |
+-----------+
| 763141 |
+-----------+
1 row in set (1.339 sec)
The SQL query is generated automatically by the DataTables library for Laravel, the explains shows:
But I'm not sure if this is correct or why it happens, there are currently about 8 million records in the table
Edit:
The execution plan for the query without limit 1
It seems that it is going through the whole table and not using the index.
The execution plan for the query with limit 1:
Apparently I was using the index and it does not go through the whole table
Table indexes:

Answer 1

This will probably run faster in both places:
SELECT COUNT(*) AS aggregate
FROM paquetes
WHERE paquetes.created_at >= "2021-10-17"
AND paquetes.created_at < "2021-10-17" + INTERVAL 1 MONTH + INTERVAL 1 DAY
AND paquetes.estado != 0;
The + INTERVAL 1 DAY was derived from your range, and may be a mistake.
More
The Optimizer, in general, has two ways to perform a query -- Use an index, or scan the table. As a simplified rule, if more than 20% of the rows are needed, it will prefer to simply scan the table; Explain will say "All". Otherwise, it will tell you which Index it picked.
When using an index, it will bounce between the Index's BTree and the Data's BTree. Since the Optimizer cannot precisely predict whether this "bouncing" will be faster or slower than simply reading all rows ('table scan') and ignoring the ones that don't meet the Where clause, it will sometimes pick the 'wrong' way to perform the query.
You are probably seeing the results of this "which way?" quandary when you change the date range.