2016-08-24 3 views
1

하나의 테이블에 여러 개의 CSS 가져 오기가 병합되었습니다.이 호출은 완료하는 데 약 70 초가 걸립니다. 속도를 높이기 위해 다시 작성하는 방법이 있습니까?SQL - 성능 향상

SELECT 
    `table_merged`.Property AS 'Property', 
    AVG(`table_merged`.`Value`) AS 'Average Asking Price' 
FROM 
    `table_merged` 
WHERE 
    `table_merged`.`Area` LIKE '%NW1%' 
    AND `table_merged`.`Property` LIKE '%2-bed flat%' 
    AND `table_merged`.`Year` = '2016' 
GROUP BY 
    `table_merged`.Property, `table_merged`.`Year` 
ORDER BY 
    `table_merged`.Property ASC 

출력은 그대로 쿼리와 함께 할 수 많은 없다

| Property | Average Asking Price 
| 2-bed flat | 751427.1935581862 
+0

당신은'% .. %' "like"와 일치합니다. 그것들은 전체 테이블 스캔을 강제하기 때문에 본질적으로 느립니다. –

+0

'좋아해요'는 정말 엉망입니다. 전체 텍스트 색인을 사용해야 할 수도 있지만 검색하는 문자열에 까다로울 수 있습니다. –

+0

2 베드 플랫에있는 LIKE를 제거했습니다.하지만 NW1에서 @GordonLinoff 전체 텍스트 색인이 향상되었습니다. –

답변

0

입니다. 지금 가장 큰 성과는 %...% 스타일 LIKE 문을 사용하는 것입니다. 논평에서 Gordon이 이미 언급했듯이, 이것은 기본적으로 인덱스를 사용하는 MySQL의 기능을 제거합니다.

여기서 가장 좋은 해결책은 스키마를 약간 변경하는 것입니다. 속성의 유형 (2- 베드 플랫과 같은)과 코드의 종류 (int 일 수 있음)를 저장하는 테이블을 만드는 것이 좋습니다. LIKE 문을 사용하지 않고 코드를 검색하면 색인을 사용할 수 있고 동일한 문자열을 절대적으로 검색해야하는 경우 더 작은 테이블에서 subselect로 검색 할 수 있습니다. 자세한 설명을 위해

편집 :

당신은 %2-bed flat% 일치하는 텍스트 문자열을 검색하고 있습니다. 내 가정은 cute 2-bed flat, 2-bed flat near the water 또는 기타 무작위 마케팅과 같은 문자열이 있기 때문에이 작업을 수행한다는 것입니다. 귀하의 LIKE 진술을 최적화 할 방법이 없습니다. 그들은 느리고 삶의 불행한 사실입니다.

현재 테이블에 열을 추가합니다. 문자열이 문자열 %2-bed flat%과 일치하면 2bf과 같은 값을 지정합니다. 이 작업을 수행하는 동안 사용할 수있는 다른 검색 문자열을 사용하여이 작업을 수행 할 수 있습니다. 이 열에 색인을 붙이십시오.

일단 완료되면 새로운 LIKE 문을 사용하는 대신 색인화 된 검색을 수행 할 수 있습니다.

+0

- 내가 별도의 테이블로 돌아가서 조인 집합을하려고하면 어떻게 될까요? –

+0

초기 테이블은 일괄 처리입니다.하지만 2013 및 2016과 같은 평균 가격을 물어 보는 쿼리를 실행해야합니다. –

+0

문제는 조인이 아니라 문제를 찾는 방법입니다. 이 스타일의 'LIKE' 문은 본질적으로 느립니다. – Jacobm001