쿼리 대 여러 쿼리


181

JOIN 쿼리가 여러 쿼리보다 빠릅니까? 기본 쿼리를 실행 한 다음 기본 쿼리의 결과를 기반으로 다른 많은 SELECT를 실행합니다.

가입하면 응용 프로그램의 디자인이 많이 복잡해지기 때문에 묻습니다.

그들이 더 빠르면 누구나 대략적으로 대략적으로 얼마만큼을 근사 할 수 있습니까? 1.5x이면 상관하지 않지만 10x이면 내가 생각합니다.


나는 그들이 더 빠를 것이라고 생각합니다. 하나의 INSERT가 10 개의 개별 INSERT 쿼리보다 훨씬 빠르다는 것을 알고 있습니다.
alex

1
여러 쿼리가 응용 프로그램에서 시작된 경우 저장 프로 시저 내에 있는지 여부가 중요 할 수 있습니다 (이 정보로 질문을 편집하십시오). 전자는 후자보다 훨씬 빠릅니다.
colithium

답변:


83

특정 사례와 관련된 답변을 제공하기에는 너무 모호합니다. 그것은 많은 것들에 달려 있습니다. Jeff Atwood (이 사이트의 창립자)는 실제로 이것에 대해 썼습니다 . 대부분의 경우 올바른 인덱스가 있고 JOIN을 올바르게 수행하면 일반적으로 여러 번보다 1 회 트립하는 것이 더 빠릅니다.


2
다른 키에서 3 개 이상의 테이블을 조인하는 경우 종종 데이터베이스 (예 : mysql)는 테이블 당 하나의 인덱스 만 사용할 수 있습니다. 즉, 조인 중 하나는 빠르며 (인덱스를 사용) 반면 다른 것은 매우 느립니다. 여러 쿼리의 경우 각 쿼리에 사용할 인덱스를 최적화 할 수 있습니다.
user151975

4
이것은 "빠른"에 대한 정의에 달려 있다고 생각합니다. 예를 들어, 3 개의 PK 내부 ​​조인은 네트워크 오버 헤드로 인해 4 번의 왕복보다 더 빠르게 돌아올 수 있으며, 이전 쿼리가 완료되었습니다. 그러나로드 상태에서 서버를 벤치마킹하는 경우 대부분의 경우 조인은 PK 쿼리보다 CPU 시간이 더 걸리고 네트워크 오버 헤드도 더 많이 발생합니다.
mindplay.dk

97

내부 조인의 경우 일치하는 행만 가져 오기 때문에 단일 쿼리가 적합합니다. 왼쪽 조인의 경우 여러 쿼리가 훨씬 낫습니다 ... 다음 벤치 마크를 살펴보십시오.

  1. 5 개의 조인이있는 단일 쿼리

    쿼리 : 8.074508 초

    결과 크기 : 2268000

  2. 연속으로 5 개의 쿼리

    결합 된 쿼리 시간 : 0.00262 초

    결과 크기 : 165 (6 + 50 + 7 + 12 + 90)

.

두 경우 모두 동일한 결과를 얻습니다 (6 x 50 x 7 x 12 x 90 = 2268000).

왼쪽 조인은 중복 데이터와 함께 기하 급수적으로 더 많은 메모리를 사용합니다.

두 테이블의 조인 만 수행하는 것이 아니라 일반적으로 3 개 이상이고 다른 쿼리의 가치가있는 경우 메모리 제한은 나쁘지 않을 수 있습니다.

참고로 MySQL 서버는 내 응용 프로그램 서버 바로 옆에 있으므로 연결 시간을 무시할 수 있습니다. 연결 시간이 초 단위라면 이점이있을 수 있습니다.

솔직한


31
우리가 자신의 올바른 마음에 아무도 5 개의 테이블 사이에 교차 결합을하지 않는다는 성가신 작은 사실을 버린다면 (그 이유 때문에 대부분의 경우 이해가되지 않습니다. ) "벤치 마크"에 장점이있을 수 있습니다. . 그러나 왼쪽 또는 내부 조인은 일반적으로 키를 기준으로 (일반적으로 검색 속도가 훨씬 빠름) 표준이며 데이터 복제는 일반적으로 데이터를 만드는 것보다 훨씬 적습니다.
cHao

12
@cHao는 누가 말합니다? 방금 SMF와 phpBB를 조회하고 3 개의 테이블 사이에서 JOIN을 보았습니다. 플러그인이나 수정을 추가하면 쉽게 추가 할 수 있습니다. 모든 종류의 대규모 응용 프로그램은 많은 JOIN에 대한 잠재력을 가지고 있습니다. 아마도 잘못 작성되었거나 잘못 사용 된 ORM은 실제로 필요하지 않은 테이블 (아마도 모든 테이블)에 참여할 수 있습니다.
Natalie Adams

5
@NathanAdams : 왼쪽 및 내부 조인은 전혀 나쁘지 않습니다. (실제로 여기저기서 테이블을 조인하지 않으면 SQL을 잘못하고 있습니다.) 내가 말한 것은 두 테이블 사이에서도 거의 바람직하지 않은 크로스 조인 입니다. 위에서 언급 한 완전히 허위 "2268000"결과를 얻는 유일한 방법입니다.
cHao

2
그래도 결과를보십시오. "결과 크기 : 2268000"대 "결과 크기 : 165". JOIN의 속도 저하는 레코드가 서로 일대 다 관계를 갖기 때문에 일대일 관계가 있으면 JOIN이 훨씬 빠르며 결과가 확실하지 않기 때문입니다. SELECT보다 큰 크기입니다.
HoldOffHunger

3
@cHao 분명히 당신은 당신의 첫 번째 코멘트 시점에 마 젠토를 만나지 않았습니다
vitoriodachef

26

이 질문은 오래되었지만 일부 벤치 마크가 누락되었습니다. 나는 두 경쟁자에 대해 JOIN을 벤치마킹했습니다.

  • N + 1 쿼리
  • (2 개) 질의하는 사용 번째 WHERE IN(...)또는 동등한

그 결과는 분명하다 : MySQL을, JOIN이다 훨씬 더 빨리. N + 1 쿼리는 응용 프로그램의 성능을 크게 떨어 뜨릴 수 있습니다.

N + 1 vs WHERE IN 가입

즉, 매우 적은 수의 별개의 외부 레코드를 가리키는 많은 레코드를 선택하지 않는 한. 극단적 인 경우에 대한 벤치 마크는 다음과 같습니다.

JOIN vs N + 1-동일한 외래 레코드를 가리키는 모든 레코드

대다 관계를 조인하지 않으면 외래 키가 다른 테이블에 있고 주 테이블 데이터를 여러 번 복제하지 않는 한 일반적인 응용 프로그램에서 발생할 가능성이 거의 없습니다.

테이크 아웃 :

  • * 대일 관계의 경우 항상 JOIN
  • * 대다 관계의 경우 두 번째 쿼리 더 빠를 있습니다.

자세한 내용은 Medium에 대한 내 기사 를 참조하십시오.


22

나는 실제로이 질문에 답을 찾고, 주어진 답변을 읽은 후에 DB 쿼리 성능을 비교하는 가장 좋은 방법은 고려할 변수가 많기 때문에 실제 숫자를 얻는 것에 만 동의 할 수 있습니다 그러나 나는 그들 사이의 숫자를 비교하면 거의 모든 경우에 좋지 않다고 생각합니다. 내 말은 숫자는 항상 허용되는 숫자와 비교해야하며 서로 확실히 비교해서는 안된다는 것입니다.

쿼리하는 한 가지 방법으로 0.02 초가 걸리고 다른 한 가지 방법으로 20 초가 걸리는 것을 이해하면 큰 차이가 있습니다. 그러나 한 쿼리 방법에 0.0000000002 초가 걸리고 다른 방법에 0.0000002 초가 걸리면 어떻게해야합니까? 두 경우 모두 하나의 방법은 무려 1000 배 빠른 다른 하나보다,하지만은 정말 두 번째 경우에 "무려"아직?

내가 개인적으로 본 결론 : 실적이 좋으면 쉬운 해결책을 찾으십시오.


4
물론 스케일링을 계획하고 있는지 여부에 따라 다릅니다. 페이스 북이 시작되었을 때 Cuz 나는 그들이 그런 종류의 쿼리를 가지고 있다고 확신하지만 스케일링을 염두에두고 더 복잡한 솔루션이지만 더 효율적으로 나아갔습니다.
dudewad

@dudewad 말이됩니다. 그것은 결국 당신이 필요로하는 것에 달려 있습니다.
Valentin Flachsel

4
하하 .. 구글에서 1 나노초의 손실은 문자 그대로 100 억 달러와 같지만 소문 일뿐입니다.
dudewad

2
@dudewad 사실, 페이스 북이 시작했을 때, 나는 그들이 더 간단한 해결책을 찾았 음을 보증합니다. 주 커버 그는 단 2 주 만에 첫 번째 버전을 프로그래밍했다고 밝혔다. 신생 기업은 경쟁하기 위해 빠르게 움직여야 하며, 생존 한 기업은 실제로 필요할 때까지 확장에 대해 걱정하지 않습니다. 그런 다음 수백만 달러를 투자 한 후 리팩터링하고 성능을 전문으로하는 록 스타 프로그래머를 고용 할 수 있습니다. 요컨대, 페이스 북은 종종 미세한 성능 향상을 위해보다 복잡한 솔루션을 원할 것이지만, 우리 대부분은 페이스 북을 프로그래밍하지 않습니다.
dallin

15

50,000 행 테이블에서 하나의 행을 선택하고 100,000 행 테이블에서 하나의 행과 조인하는 빠른 테스트를 수행했습니다. 기본적으로 다음과 같습니다.

$id = mt_rand(1, 50000);
$row = $db->fetchOne("SELECT * FROM table1 WHERE id = " . $id);
$row = $db->fetchOne("SELECT * FROM table2 WHERE other_id = " . $row['other_id']);

vs

$id = mt_rand(1, 50000);
$db->fetchOne("SELECT table1.*, table2.*
    FROM table1
    LEFT JOIN table1.other_id = table2.other_id
    WHERE table1.id = " . $id);

두 가지 선택 방법은 50,000 읽기에 3.7 초가 걸렸지 만 집에서 느린 컴퓨터에서는 JOIN이 2.0 초에 걸렸습니다. INNER JOIN과 LEFT JOIN은 차이가 없었습니다. 여러 행을 가져 오면 (예 : IN SET 사용) 비슷한 결과가 나타납니다.


1
어쩌면 일반적인 웹보기 그리드와 같이 행 페이지 (예 : 20 또는 50)를 선택하고 단일 LEFT JOIN을 두 쿼리와 비교하면 일부 기준으로 2 또는 3 개의 식별자를 선택한 다음 다른 쿼리를 실행하면 차이가 다르게 나타날 수 있습니다 IN ()을 사용하여 쿼리를 선택하십시오.
JustAMartin

열 id 및 other_id가 색인되어 있습니까?
Aarish Ramesh

11

실제 질문은 다음 같습니다. 이 레코드는 일대일 관계 또는 일대 다 관계 입니까?

TLDR 답변 :

일대일 인 경우, JOIN명세서를 사용하십시오 .

일대 SELECT다인 경우 서버 측 코드 최적화와 함께 하나 이상의 명령문을 사용하십시오.

최적화를 위해 SELECT를 사용하는 이유와 방법

SELECT일대 다 관계를 기반으로하는 대규모 레코드 그룹에서 '조인 대신 여러 쿼리를 사용 JOIN' 하면 '지수 적으로 메모리 누수 문제가 발생 하므로 최적의 효율성을 얻을 수 있습니다. 모든 데이터를 가져온 다음 서버 측 스크립팅 언어를 사용하여 정렬하십시오.

SELECT * FROM Address WHERE Personid IN(1,2,3);

결과 :

Address.id : 1            // First person and their address
Address.Personid : 1
Address.City : "Boston"

Address.id : 2            // First person's second address
Address.Personid : 1
Address.City : "New York"

Address.id : 3            // Second person's address
Address.Personid : 2
Address.City : "Barcelona"

여기서는 하나의 select 문에서 모든 레코드를 가져옵니다. 이것은 JOIN다른 쿼리의 하위 구성 요소로 한 번에 하나씩 작은 그룹의 레코드를 가져 오는 것 보다 낫습니다 . 그런 다음 서버 측 코드로 구문 분석합니다 ...

<?php
    foreach($addresses as $address) {
         $persons[$address['Personid']]->Address[] = $address;
    }
?>

최적화에 JOIN을 사용하지 않을 경우

JOIN하나의 단일 레코드와 일대일 관계를 기반으로 한 큰 레코드 그룹을 작성하면 여러 SELECT명령문에 비해 최적의 효율성을 얻을 수 있으며 이는 단순히 다음 레코드 유형을 가져옵니다.

그러나 JOIN일대 다 관계로 레코드를 가져올 때 비효율적입니다.

예 : 데이터베이스 블로그에는 3 개의 관심 테이블 (블로그 포스트, 태그 및 주석)이 있습니다.

SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;

블로그 게시물 1 개, 태그 2 개, 댓글 2 개가 있으면 다음과 같은 결과가 나타납니다.

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,

각 레코드가 어떻게 복제되는지 확인하십시오. 좋아요, 2 개의 댓글과 2 개의 태그는 4 행입니다. 댓글 4 개와 태그 4 개가 있으면 어떻게 되나요? 당신은 8 개의 줄을 얻지 못합니다-당신은 16 개의 줄을 얻습니다 :

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,

더 많은 테이블, 더 많은 레코드 등을 추가하면 문제는 대부분 중복 데이터로 가득 찬 수백 개의 행으로 빠르게 팽창합니다 .

이 중복 비용은 얼마입니까? 메모리 (SQL 서버 및 중복 제거를 시도하는 코드) 및 네트워킹 리소스 (SQL 서버와 코드 서버 간)

출처 : https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html ; https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html


당신은 요점을 그리워합니다. 일대일이 아닙니다. 행 집합이 서로 쌍을 이룰 수 있는지 여부에 관한 것입니다. 접선 적으로 관련된 두 개의 데이터 세트 만 요청합니다. 의견을 요청하는 경우 (예 : 작성자의 연락처 정보) 사람들이 둘 이상의 의견을 쓸 수 있지만 조인으로 더 의미가 있습니다.
cHao

@ cHao : 귀하의 의견에 감사드립니다. 위의 내 대답은 MySQL의 문서의 요약은 여기에서 찾을 수 있습니다 : dev.mysql.com/doc/workbench/en/wb-relationship-tools.html
HoldOffHunger

그것은 MySQL 문서가 아닙니다. MySQL 데이터베이스 작업을위한 특정 GUI 도구에 대한 설명서입니다. 또한 조인이 적절한 지 (또는 적합하지 않은 경우)에 대한 지침을 제공하지 않습니다.
cHao

@cHao : 죄송합니다. MySQL Server (TM)가 아니라 MySQL WorkBench (TM)에 대한 MySQL 설명서가 있습니다.
HoldOffHunger 2016 년

Pedantry는 제쳐두고 관련성이 명확하지 않습니다. 둘 다 일대일 관계와 일대 다 관계를 언급하지만 그것이 공통점이 끝나는 곳입니다. 어느 쪽이든, 문제는 데이터 세트 간의 관계에 관한 것입니다. 관련없는 두 세트에 참여하면 두 가지 조합을 모두 얻을 수 있습니다. 관련 데이터를 여러 선택으로 나누면 의심스러운 이익을 위해 여러 쿼리를 수행하고 MySQL 작업을 시작했습니다.
cHao

8

별도의 쿼리와 조인을 모두 구성한 다음 각각의 시간을 정하십시오. 실제 숫자보다 큰 도움은 없습니다.

더 나은 방법은 각 쿼리의 시작 부분에 "EXPLAIN"을 추가하는 것입니다. 이것은 MySQL이 데이터 요청에 응답하기 위해 사용하는 서브 쿼리 수와 각 쿼리에 대해 스캔 된 행 수를 알려줍니다.


7

개발자의 복잡성에 비해 데이터베이스의 복잡성에 따라 많은 SELECT 호출을 수행하는 것이 더 간단 할 수 있습니다.

JOIN과 다중 SELECTS에 대해 일부 데이터베이스 통계를 실행하십시오. 환경에서 JOIN이 SELECT보다 빠르거나 느린 지 확인하십시오.

그런 다음 다시 JOIN으로 변경하면 추가 일 / 주 / 월 개발 작업을 의미하는 경우 여러 SELECT를 사용합니다.

건배,

BLT


5

내 경험상, 특히 큰 데이터 세트를 검색 할 때 여러 쿼리를 실행하는 것이 일반적으로 더 빠릅니다.

PHP와 같은 다른 응용 프로그램에서 데이터베이스와 상호 작용할 때 한 서버를 여러 번 방문해야한다는 주장이 있습니다.

서버로의 트립 수를 제한하고 종종 더 빠를뿐만 아니라 응용 프로그램을보다 쉽게 ​​읽을 수있는 여러 쿼리를 실행하는 다른 방법이 있습니다 (예 : mysqli_multi_query).

나는 SQL에 관해서 초보자가 아니며, 개발자, 특히 주니어는 똑똑해 보이기 때문에 매우 영리한 조인을 작성하는 데 많은 시간을 소비하는 경향이 있다고 생각하지만 실제로는 데이터를 추출하는 현명한 방법이 있습니다 단순한.

마지막 단락은 개인적인 의견이지만 이것이 도움이되기를 바랍니다. 누가 벤치마킹해야한다고 말하지만 다른 사람들과 동의합니다. 두 가지 방법 모두 은총 알이 아닙니다.


그렇습니다. 쿼리 자체뿐만 아니라 응용 프로그램 내부의 데이터 처리도 고려해야합니다. 외부 조인을 사용하여 데이터를 가져 오는 경우 앱 (일반적으로 일부 ORM 라이브러리에서)별로 정렬해야하는 중복성 (때로는 실제로 너무 커질 수 있음)이 있으므로 JOIN 쿼리가있는 단일 SELECT가 더 많은 CPU 및 두 개의 간단한 선택보다 시간
JustAMartin

4

조인을 사용해야하는지 여부는 무엇보다 조인 이 의미 가 있는지에 대한 것 입니다. 거의 모든 경우에 성능이 크게 저하 되므로 그 시점에서만 성능을 고려해야 합니다.

성능 차이는 주로 쿼리하는 정보가 얼마나 관련성이 있는지에 달려 있습니다. 조인은 작동 하며 데이터가 관련되어 있고 올바르게 색인을 생성 할 때 빠르지 만 종종 중복성과 결과가 필요한 것보다 더 많습니다. 그리고 데이터 세트가 직접 관련되어 있지 않은 경우 단일 쿼리에서 데이터 세트를 고수하면 Cartesian 제품 (기본적으로 가능한 모든 행 조합)이 만들어 지므로 원하는 것은 아닙니다.

이것은 종종 일대 다 관계에 의해 발생합니다. 예를 들어 HoldOffHunger의 답변 은 게시물, 태그 및 주석에 대한 단일 쿼리를 언급했습니다. 댓글은 태그와 마찬가지로 게시물과 관련이 있지만 태그는 댓글과 관련이 없습니다.

+------------+     +---------+     +---------+
|  comment   |     |   post  |     |  tag    |
|------------|*   1|---------|1   *|---------|
| post_id    |-----| post_id |-----| post_id |
| comment_id |     | ...     |     | tag_id  |
| user_id    |     |         |     | ...     |
| ...        |     |         |     | ...     |
+------------+     +---------+     +---------+

이 경우에는 적어도 두 개의 별도 쿼리 인 것이 분명합니다. 태그와 주석을 결합하려고하면 둘 사이에 직접적인 관계가 없기 때문에 가능한 모든 태그와 주석 조합으로 끝납니다. many * many == manymany. 그 외에도 게시물과 태그는 관련이 없으므로 두 쿼리를 병렬로 수행하여 잠재적 인 이익을 얻을 수 있습니다.

그러나 다른 시나리오를 고려해 봅시다. 게시물에 댓글을 달고 댓글 작성자의 연락처 정보를 원합니다.

 +----------+     +------------+     +---------+
 |   user   |     |  comment   |     |   post  |
 |----------|1   *|------------|*   1|---------|
 | user_id  |-----| post_id    |-----| post_id |
 | username |     | user_id    |     | ...     |
 | ...      |     | ...        |     +---------+
 +----------+     +------------+

여기에서 조인을 고려해야합니다. 훨씬 더 자연스러운 쿼리 일뿐만 아니라 대부분의 데이터베이스 시스템 (MySQL 포함)에는 많은 똑똑한 사람들이 쿼리 최적화에 많은 노력을 기울이고 있습니다. 별도의 쿼리의 경우 각 쿼리는 이전 쿼리의 결과에 따라 달라 지므로 쿼리를 병렬로 수행 할 수 없으며 총 시간은 쿼리의 실제 실행 시간뿐만 아니라 결과를 가져 오는 데 소요 된 시간이됩니다. 다음 쿼리의 ID를 통해 행을 연결하는 등


두 번째 시나리오에서 많은 사용자 열을 검색하고 동일한 사용자가 두 번 이상 주석을 추가해도 별도의 쿼리에서 가장 잘 검색되는지 여부에 대한 질문이 여전히 남아 있습니다.
Adrian Baker

@AdrianBaker : 내가 말했듯이, 많은 똑똑한 사람들이 많은 노력을 기울이고 있습니다. SQL 서버를 최적화하려는 경우 첫 번째 아이디어는 압축을 사용하여 코드를 변경하지 않고도 엄청난 양의 중복성을 제거하는 것입니다. 전혀. 다음 수준의 최적화에는 결과를 테이블로 재구성하고 튜플의 행 ID와 함께 결과를 전송하는 것이 포함되며, 클라이언트 라이브러리는 필요에 따라 측면에서 쉽게 조립할 수 있습니다.
cHao

이러한 최적화는 중복을 줄이거 나 없애기 위해 조인으로 놀라운 일을 할 수 있지만 관련 레코드를 가져 오기 위해 수행해야 할 본질적인 직렬 쿼리를 도울 수있는 것은 많지 않습니다.
cHao

3

처리량 측면에서 더 빠릅니까? 아마. 그러나 데이터베이스와 스키마에 따라 한 번에 더 많은 데이터베이스 개체를 잠글 수 있으므로 동시성이 줄어 듭니다. 내 경험상 사람들이 데이터베이스가 같은 LAN에있는 대부분의 OLTP 시스템에서 실제로 "더 적은 데이터베이스 라운드 트립"이라는 주장으로 오도되는 경우가 있습니다. 실제 병목 현상은 거의 네트워크가 아닙니다.


2

다음은 100 개의 유용한 쿼리가있는 링크입니다. 이들은 Oracle 데이터베이스에서 테스트되었지만 SQL이 표준이라는 것을 기억하십시오. Oracle, MS SQL Server, MySQL과 다른 데이터베이스의 차이점은 SQL 언어입니다.

http://javaforlearn.com/100-sql-queries-learn/


1

이진 답변이 없다는 것을 의미하는 몇 가지 요소가 있습니다. 성능에 가장 적합한 것은 환경에 따라 다릅니다. 그런데 식별자가있는 단일 선택이 1 초 미만이 아닌 경우 구성에 문제가있을 수 있습니다.

실제 질문은 어떻게 데이터에 액세스하길 원하는지입니다. 단일 선택은 후기 바인딩을 지원합니다. 예를 들어 직원 정보 만 원하는 경우 직원 테이블에서 선택할 수 있습니다. 외래 키 관계를 사용하여 나중에 필요한 경우 관련 리소스를 검색 할 수 있습니다. 선택은 이미 지적해야 할 열쇠가 있으므로 매우 빠르며 필요한 항목 만 검색하면됩니다. 네트워크 대기 시간은 항상 고려해야합니다.

조인은 모든 데이터를 한 번에 검색합니다. 보고서를 생성하거나 그리드를 채우는 경우 정확히 원하는 것일 수 있습니다. 이 시나리오에서는 컴파일 및 옵토마 이즈 된 조인이 단일 선택보다 빠를 것입니다. Ad-hoc 조인은 빠르지 않을 수 있으므로이를 저장 프로 시저로 컴파일해야합니다. 속도 응답은 DBMS가 데이터를 검색하기 위해 수행하는 단계를 정확히 설명하는 실행 계획에 따라 다릅니다.


0

예, JOINS를 사용하는 하나의 쿼리가 더 빠릅니다. 쿼리하는 테이블의 관계, 데이터 집합의 크기 또는 기본 키의 위치를 ​​모르더라도 얼마나 빨리 말하는지는 거의 불가능합니다.

두 시나리오를 모두 테스트 해보십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.