하위 쿼리에 임의의 상한이 지정된 경우 MariaDB가 다르게 동작하는 이유는 무엇입니까?

하위 쿼리에 임의의 상한이 지정된 경우 MariaDB가 다르게 동작하는 이유는 무엇입니까?

다음 쿼리는 MariaDB 5.5.40의 "filesort"를 사용합니다.완료하는 데 약 9초가 걸립니다.둘다요.sos그리고.quotes꽤 큰 테이블이지만, 미친 것은 아닙니다.

explain
select  SQL_NO_CACHE
`quotes`.`QuoteName`
FROM 
`worknet`.`quotes`
LEFT JOIN `worknet`.`sostatus` AS `sostatusDB` ON `quotes`.`dnum`=`sostatusDB`.`so`  
LEFT JOIN 
(SELECT `dnum` from `worknet`.`sos`) AS `sosStatusDb`
ON `quotes`.`dnum`=`sosStatusDB`.`dnum` 
where `quotes`.`deleted` IS NULL
ORDER BY `quotes`.`dateModified` DESC 
LIMIT 100

1   PRIMARY <derived2>  ALL                 100 Using where; Using temporary; Using filesort
1   PRIMARY sos index   PRIMARY SONUM   18      179433  Using where; Using index; Using join buffer (flat, BNL join)
2   DERIVED quotes  index       date_modified   5       100 Using where

그러나 하위 쿼리에 인위적인 제한을 만들면 모든 것이 바뀝니다(더 좋아집니다!).하위 쿼리 라인을 아래의 제한 라인으로 바꿉니다.

(SELECT `dnum` from `worknet`.`sos` LIMIT 18446744073709551615)  AS `sosStatusDb`

1   PRIMARY <derived2>  ALL                 100 Using where; Using temporary; Using filesort
1   PRIMARY <derived3>  ALL                 179433  Using where; Using join buffer (flat, BNL join)
3   DERIVED sos index       SONUM   18      179433  Using index
2   DERIVED quotes  index       date_modified   5       100 Using where

이제 쿼리 시간은 9.1초에서 0.078초로 단축되었습니다.

그래서 분명히, 한계는 엔진이 더 나은 알고리즘을 사용하도록 설득하고 있습니다. 하지만 왜 그럴까요?제가 부과한 한계는 매우 크고(2^64-1) 아무 영향도 주지 않지만 시간이 크게 향상됩니다.옵티마이저에 버그가 있는 것 같지만 성능을 개선할 다른 방법을 찾을 수 없습니다.

언급URL : https://stackoverflow.com/questions/26393529/why-does-mariadb-behave-differentyly-when-an-arbitrarily-high-limit-is-placed-on