Pergunta

have an issue with MariaDB 10.2.12 running in aws rds (single master, no slave)

when I run prepared statement using a variable substitution

PREPARE stmt1 FROM 
"select ...quite complex select from tenth of tables..
 and `subscribers`.`id` = ?
 group by `subscribers`.`id`
 limit 1";
SET @a = 77586744;
EXECUTE stmt1 USING @a;  
DEALLOCATE PREPARE stmt1;

it takes 13 minutes to process (those tables have millions rows)

however, if I run the very same query without variableS:

SET @sql = CONCAT("select ...quite complex select from tenth of tables..
 and `subscribers`.`id` = ",77586744,"
 group by `subscribers`.`id`
 limit 1");
PREPARE stmt1 FROM @sql;
EXECUTE stmt1 ;  
DEALLOCATE PREPARE stmt1;

it only needs 0.05s to run. The same time it takes if I not use PREPARE at all.

According to profiler output the long run involves several "converting HEAP to Aria" with reindexing and sorting it, which do not take place if no variable involved.

Why do this converting happen? it seems there is no lack in tmp/heap since the query runs in 0.05s, thus it's "USING variable" changes something I don't know.

btw, we've faced the issue running application on PHP 7.1.20 with Laravel Framework 5.6.39, so I cannot just rewrite a query to get rid of "USING variable" as it something that happens under the hood of PDO.

0.05s 769.20s

UPD: EXPLAIN for slow query enter image description here

EXPLAIN for fast one enter image description here

OK, explain differs, but it's kind of expected from profilier output. The thing I still don't get is why it differs while the query stays the same.

Foi útil?

Solução

Is subscriber_tag a many:many mapping table? Ditto for segmentation_tag? If so, there may be several ways to speed up the use of such on both versions. See here.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a dba.stackexchange
scroll top