2013-12-19 3 views
2

테이블 정의를 최적화하고 인덱스는 같은쿼리가 더 이상 실행 중입니다. 제안을

CREATE TABLE `asin` (
    `ASIN` tinytext, 
    `URL` tinytext, 
    KEY `ind1` (`ASIN`(20)) 
) ENGINE=MyISAM DEFAULT 

CREATE TABLE `info` (
    `ASIN` tinytext, 
    `Title` tinytext, 
    `Description` tinytext, 
    KEY `ind1` (`ASIN`(20)), 
    KEY `ASIN` (`ASIN`(20)) 
) ENGINE=MyISAM DEFAULT 

현재 1 표는 15,056 레코드를 포함, 2 표는 19,975 레코드를 포함 아래.

나는 ASIN 테이블의 레코드 존재를 찾아 쿼리 145.2200 초 나는 이것이 효율적인 방법 쿼리가 작동 할 것입니다 생각

했다

SELECT A.ASIN FROM ASIN A 
WHERE NOT EXISTS (SELECT 1 FROM INFO B WHERE A.ASIN = B.ASIN) 

정보 테이블에 존재하지 싶지만 쿼리입니다 더 많은 시간을. 어떠한 제안. 나는 모든 세부 사항을 제공하기를 바랍니다.

+0

이 문서가 도움이 될 것입니다 http://explainextended.com/2009/09/18/not-in- vs-not-exist-vs-left-join-is-null-mysql/ – Meherzad

답변

0

역방향 좌 결합을 사용하십시오!

SELECT a.asin 
FROM asin AS a 
LEFT JOIN info AS b ON a.ASIN=b.ASIN 
WHERE b.ASIN IS NULL 
+0

나는 그 옵션을 이미 시도했지만, 현재 시간보다 더 오래 걸리지 않았다. 그것의 복용 228.010 Sec – user3117500

+0

예, Varchar로 변경 후 이것은 더 빠르게 실행됩니다. 그러나 Tinytext에서는 빠르게 실행되지 않습니다. – user3117500

+0

Tinytext는 조인 색인을 사용할 수 없습니다. VARCHAR은 조인 색인을 사용할 수 없습니다. 이것은 큰 차이를 만듭니다. –

1

는 "이미 해당 옵션을 시도했다, 그러나 개선은 현재 시간 이상을 복용하지 않습니다."

는 나는 당신이

  1. TINYTEXTVARCHAR(255)에 evalent되어 ASIN

    디자인 고려 사항에 20 바이트 접두사 인덱스를 사용하는 것 같아요. 디스크 공간과 관련이 없다면 20 바이트 접두사 INDEX에 대한 이유는 없습니다. asininfo 사이

    CREATE TABLE `asin` (
        `ASIN` VARCHAR(255), 
        `URL` VARCHAR(255), 
        KEY `ind1` (`ASIN`) 
    ) ENGINE=MyISAM DEFAULT; 
    
    CREATE TABLE `info` (
        `ASIN` VARCHAR(255), 
        `Title` VARCHAR(255), 
        `Description` VARCHAR(255), 
        KEY `ind1` (`ASIN`) 
    ) ENGINE=MyISAM DEFAULT; 
    
  2. 관계. 1-1? 일대 다?, 일대일의 경우. 두 테이블을 하나의 테이블로 병합하십시오.

    CREATE TABLE `asin` (
        `ASIN` VARCHAR(255), 
        `URL` VARCHAR(255), 
        `Title` VARCHAR(255), 
        `Description` tinytext, 
        KEY `ind1` (`ASIN`) 
    ) ENGINE=MyISAM DEFAULT; 
    
  3. 당신은 기본 키에게의 MyISAM 관련

    • 하지 성능이 필요합니다. 그러나 PK를 갖는 것은 좋은 습관입니다.
  4. 사용 이노 대신의 MyISAM

    보다는
    • 당신은 FK를 사용할 수 있습니다.
    • 행 수준 잠금
    • 거래
    • 클러스터 INDEX (해당 PK)
+0

디스크 공간에 관한 것이 아닌 한 20 바이트 접두어 INDEX에 대한 이유는 없습니다. 디스크 공간과 관련이 없다면 20 바이트 접두어 INDEX에 대한 이유가 없습니다. 그리고 VARCHAR 제안에 대해서는 놀랍습니다. 테이블을 선언하고 동일한 데이터를로드 한 후 쿼리는 초의 부분에서 실행되었습니다. 고마워요 많은 – user3117500

+0

@ user3117500 내 기쁨 ;-) 마지막으로 왜 Eugen의 LEFT JOIN/IS NULL 쿼리를 실행하지 않는가? 나는 그것이 '존재하지 않는다'것보다 조금 더 빠르다고 생각한다. 나는 당신과 Eugen 's를 시험하고 그 결과를 알려주는지 궁금합니다. 고맙습니다. –

+0

예, Varchar로 변경하면 더 좋습니다. TINYTEXT 선언을 사용하여 쿼리를 테스트했습니다. – user3117500

관련 문제