MariaDB가 한 데이터베이스에 대해 종속 하위 쿼리에 대해 색인을 사용하지 않지만 동일한 서버에 있는 다른 데이터베이스에는 사용하지 않음

MariaDB가 한 데이터베이스에 대해 종속 하위 쿼리에 대해 색인을 사용하지 않지만 동일한 서버에 있는 다른 데이터베이스에는 사용하지 않음

라이브 데이터베이스에서 테스트 데이터베이스로 복사할 때 갑자기 속도가 느려진 응용 프로그램이 있습니다.두 데이터베이스는 동일한 서버에 있으며 테스트 데이터베이스는 실시간 데이터의 mysqdump에서 작성되었습니다.그래서 그들은 같은 경우에 동일합니다.

두 데이터베이스에 대한 느린 쿼리를 설명하면, 하나는 색인을 사용하고 다른 하나는 그렇지 않습니다.이는 둘 이상의 쿼리 유형에서 발생하지만 한 가지 예를 보여드리겠습니다.

실행 중인 쿼리는 다음과 같습니다.

SELECT * FROM  product
INNER JOIN product_category pc
ON product.id = pc.product_id
INNER JOIN category c
ON c.id = pc.category_id
WHERE
(c.discount_amount > 0 OR c.discount_percent > 0)
AND (c.`discount_start_date` <= NOW() OR c.`discount_start_date` IS NULL)
AND (c.`discount_end_date` >= NOW() OR c.`discount_end_date` IS NULL)

라이브 데이터베이스의 EXPLE 결과는 다음과 같습니다.

이드	select_type	테이블	유형	possible_key	열쇠	key_len	심판을 보다	행들	추가의
1	간단하죠.	c	index_include	주, 범주_할인_시작_날짜, 범주_할인_종료_날짜, 범주_할인_금액, 범주_할인_퍼센트	범주_category_mount,category_message_percent	8,8	NULL	10	sort_union 사용(category_discount_금액, category_discount_percent);사용 위치
1	간단하죠.	pc	심판을 보다	카테고리_id,제품_id	category_id	4	rollipop_site.c.id	19
1	간단하죠.	제품.	eq_ref	기본적인	기본적인	4	rollipop_site.pc.product_id	1

다음은 테스트 데이터베이스의 EXPLE 결과입니다.

이드	select_type	테이블	유형	possible_key	열쇠	key_len	심판을 보다	행들	추가의
1	간단하죠.	제품.	모든.	기본적인	NULL	NULL	NULL	1
1	간단하죠.	pc	모든.	카테고리_id,제품_id	NULL	NULL	NULL	1	위치 사용; 조인 버퍼 사용(플랫, BNL 조인)
1	간단하죠.	c	eq_ref	주, 범주_할인_시작_날짜, 범주_할인_종료_날짜, 범주_할인_금액, 범주_할인_퍼센트	기본적인	4	rollipop_dll.pc.lolip_id	1	사용 위치

저는 도커 버전 10.7.3-MariaDB-1:10.7.3+maria~focal에서 MariaDB를 사용하고 있습니다.

서버가 다른 데이터베이스에 있는 동일한 데이터에 대해 동일한 쿼리에 대해 다른 쿼리 계획을 사용하는 이유를 누군가가 밝혀줄 수 있기를 바랍니다.

이 쿼리는 이전에 사용되었습니다.WHERE id IN (SELECT product_id FROM...다른 스택 오버플로 답변에서 권장하는 대로 변환했습니다.이 설치에도 이 문제가 있는 쿼리가 여러 개 있습니다.

두 개의 다른 mariadb 서버에서 기본 키를 사용하지 않는 쿼리와 유사한 문제가 있습니다.Maridb는 정확히 동일한 버전에 있으며 구성도 동일합니다.제 질문은 다음과 같습니다.

select .....
    from model_number mn
             inner join manufacturer m on (mn.manufacturer_id = m.id)
             inner join product_type pt on (mn.product_type_id = pt.id)
             inner join user cu on cu.id = mn.created_by
             inner join user uu on uu.id = mn.updated_by
             inner join replacement r on (mn.id = r.model_number_by_id)
             inner join mapping ma on r.model_number_by_id = ma.model_number_id and r.physical_item_type_id = ma.physical_item_type_id
    where r.model_number_id = 1355
      and r.physical_item_type_id = 4

인덱스(기본 키)가 form, pt, cu 및 uu 형식을 사용하지 않습니다.

또한 쿼리 계획의 순서가 다릅니다.

server using primary keys:     r,mn,uu,pt,m,cu,ma
server not using primary keys: r,m,pt,cu,uu,mn,ma

나는 접착제가 없어 뭐가 잘못됐어요.

다음은 모든 것이 예상대로 작동하는 서버의 쿼리 계획입니다.

이드	select_type	테이블	유형	possible_key	열쇠	key_len	심판을 보다	행들	추가의
1	간단하죠.	r	심판을 보다	주,fk_replacement_model_number_by,fk_replacement_physical_item_type	fk_교체_물리적_항목_유형	8	상수, 상수	3	인덱스 사용
1	간단하죠.	음	eq_ref	주, 모델_number_unq_idx2,fk_모델_number_user_c,fk_model_number_user_u,fk_model_number_product_type	기본적인	4	vat_vat.r.model_number_by_id	1	사용 위치
1	간단하죠.	유우	eq_ref	기본적인	기본적인	1	vat_bat.mn.mn.bat_by	1
1	간단하죠.	pt의	eq_ref	기본적인	기본적인	4	vat_vat.mn.product_type_id	1
1	간단하죠.	m	eq_ref	기본적인	기본적인	4	vat_vat.mn.mn.제조사_id	1
1	간단하죠.	CU	eq_ref	기본적인	기본적인	1	vat_vat.mn.created_by	1
1	간단하죠.	엄마.	심판을 보다	old_module_uniq_idx,fk_old_dumping_physical_item_type	old_module_uniq_idx	8	vat_vat.r.model_number_by_id, const	1	인덱스 사용

인덱스가 사용되지 않는 서버의 쿼리 계획은 다음과 같습니다.

이드	select_type	테이블	유형	possible_key	열쇠	key_len	심판을 보다	행들	추가의
1	간단하죠.	r	심판을 보다	주,fk_replacement_model_number_by,fk_replacement_physical_item_type	fk_교체_물리적_항목_유형	8	상수, 상수	1	인덱스 사용
1	간단하죠.	m	모든.	기본적인	NULL	NULL	NULL	1	조인 버퍼 사용(플랫, BNL 조인)
1	간단하죠.	pt의	모든.	기본적인	NULL	NULL	NULL	1	조인 버퍼 사용(증분, BNL 조인)
1	간단하죠.	CU	모든.	기본적인	NULL	NULL	NULL	1	조인 버퍼 사용(증분, BNL 조인)
1	간단하죠.	유우	모든.	기본적인	NULL	NULL	NULL	1	조인 버퍼 사용(증분, BNL 조인)
1	간단하죠.	음	eq_ref	주, 모델_number_unq_idx2,fk_모델_number_user_c,fk_model_number_user_u,fk_model_number_product_type	기본적인	4	vat_vat.r.model_number_by_id	1	사용 위치
1	간단하죠.	엄마.	심판을 보다	old_module_uniq_idx,fk_old_dumping_physical_item_type	old_module_uniq_idx	8	vat_vat.r.model_number_by_id, const	1	인덱스 사용

언급URL : https://stackoverflow.com/questions/72174943/mariadb-not-using-indexes-for-dependent-subqueries-for-one-database-but-not-anot