MySQL 5.5를 사용 중입니다. 하위 쿼리를 사용하는 쿼리 (fulltext)가 있습니다. 성능 및 페이지 매김을 사용한다는 사실을 돕기 위해 LIMIT을 사용하여 결과의 수를 제한하고 있습니다.개수 최적화 및 쿼리 선택
SELECT *
FROM (
SELECT id, type, type_id, content, MATCH(content) AGAINST('john') as relevance, IFNULL (parent_type, UUID()) as parent_type, IFNULL(parent_id, UUID()) as parent_id
FROM search_index
WHERE MATCH(content) AGAINST('john*' IN BOOLEAN MODE) GROUP BY parent_type, parent_id) as search
GROUP BY search.type, search.type_id DESC LIMIT 10;
그 외에도 가능한 모든 결과 (예 : 50000)를 각 검색어와 함께 보내야합니다. 카운트를 얻으려면 다음을 사용합니다.
SELECT COUNT(*) FROM(
SELECT *
FROM (
SELECT id, type, type_id, content, MATCH(content) AGAINST('john') as relevance, IFNULL (parent_type, UUID()) as parent_type, IFNULL(parent_id, UUID()) as parent_id
FROM search_index
WHERE MATCH(content) AGAINST('john*' IN BOOLEAN MODE) GROUP BY parent_type, parent_id) as search
GROUP BY search.type, search.type_id) as count;
이렇게하면 다소 불편합니다. 다음은이 카운트 쿼리에 대한 설명입니다 :
search_index
이 content
에 전체 텍스트 인덱스입니다. search_index_no_ft
은 content
및 id
을 제외한 모든 열에 대한 색인입니다. id
에 기본 키가 있습니다.
이렇게하는 것이 더 좋은 방법일까요? 아마도 이것을 최적화하는 방법일까요? 또는 2 개의 쿼리 (개수 및 검색)를 1로 결합하는 방법이 있습니까?
정확한 일치 횟수가 필요합니까? Google에 대한 추정치 만 표시해야하는 이유가 있어야합니다. – piotrm
대부분의 경우 작동하는 페이지 매김을 생성하기 위해 정확한 일치 항목 번호가 필요합니다 (예 : 사용자 목록 필터링 및 검색 등). 일반적인 사이트 링크 인 경우, 데이터 검색 량이 너무 많아서 사용자가 어쨌든 모든 데이터를 처리하지 못한다면 나는 예상치에 만족합니다. 그렇습니다. 유스 케이스와 정확히 일치해야합니다. – F21
일부 사용자는 어쨌든 그렇게 할 수있게하려고 시도 할 것입니다. 한도에 기반한 페이지 매김이있는 웹 사이트에서 가장 높은 오프셋을 악용하는 것은 일반적인 공격 유형입니다. – piotrm