MySQL 키 딜레마

Question

MySQL 테이블에 데이터를 캐시하는 테이블 (memcached를 공유하지 않으므로)이 있습니다.

나는 페이지가로드되는 정적 데이터 후 다음 캐시 :

개념은 이것이다는 페이지를 조회

• 캐시가 다음 존재하지 않는 경우 다음 HTML 렌더링 및 캐시 테이블에 저장하십시오.
• 페이지가 캐시에 없으면 12 개의 쿼리 (메뉴, 페이지 콘텐츠, SEO, 제품 목록 등)를 실행 한 다음 렌더링 된 HTML을 테이블에 저장합니다.

캐시 테이블은 다음과 같이이다 :

이

=cache= 
url varchar(255) - primary key 
page mediumtext 

지금 나는 내가 (공유 호스트, memcached와 같은 캐싱 등)을 가지고 있지만 내 무엇을 기준으로, 옳은 일을하고 있다고 생각 URL이 varchar 인덱스하지만 때문에

때문에 숫자 ID를 (같은 int)이다 빠르고, 고유 한 정수로 /contact-us/ 또는 /product-category/product-name/ 같은 URL을 변환하는 방법이 : 질문이 무엇입니까? 아니면 이것을 최적화 할 다른 방법이 있습니까?

Answer 1

더 짧은 키를 허용하는 해시 양식을 만들 것입니다. 많은 경우 요청 경로의 해시와 같은 단순한 것이 실행 가능할 수 있습니다. 또는 CRC32 ('/ your/path/here')와 같은 간단한 것이 사용자의 상황에 기본 키로 적합 할 수도 있습니다. 이 예제에서는 다음과 같은 열이

가

urlCRC INT(11) UNSIGNED NOT NULL (PRIMARY KEY) 
url VARCHAR(255) NOT NULL 
page MEDIUMTEXT 

그런 다음 한 단계 더이 걸릴 수 존재하고

NEW.urlCRC = CRC32(NEW.url) 

당신은 다음을 만들 수 있습니다 함유 한 urlCRC에 대한 값을 계산합니다 트리거 BEFORE INSERT를 추가합니다 인수 inURL (문자열)을 취 저장 프로 시저 및 반환되는 행의 수가 0 인 경우 내부적으로는 다음 삼각 수

SELECT * FROM cacheTable WHERE urlCRC = CRC32(inURL); 

할 것 그것을 캐쉬하기위한 논리.

물론 이것은 과도 할 수도 있지만 충돌이 없다고 가정하면 작업 할 숫자 키를 제공 할 수 있습니다. url을 VARCHAR (255)로 저장하면 충돌이 발생해도 다른 알고리즘을 사용하여 새 해시를 쉽게 다시 생성 할 수 있습니다.

그냥 머리 꼭대기에서 CRC32()를 사용하는 것이 더 적합한 알고리즘입니다. 빼낼 주요 포인트는 숫자 키가 검색하는 것이 더 효율적이므로 문자열을 고유 한 숫자로 변환 할 수 있으면 데이터를 검색 할 때 더 효율적이라는 것입니다.

Answer 2

표에 동적 크기가 다른 열 (TEXT)이없는 경우 URL 열을 고정 크기 문자열로 변경하면 색인 생성이 약간 더 빨라집니다. URL 구조에 따라 정수로 변환하는 것도 가능합니다. 해시 함수를 사용할 수도 있습니다. 그러나 당신은 왜 당신의 인생을 더 쉽게 만들어주지 않습니까?

캐시 결과를 디스크에 직접 저장할 수 있으며 파일이있는 경우 일치하는 mod_rewrite 필터를 만들 수 있습니다. 그렇지 않으면 PHP 스크립트가 호출됩니다. 여기에는 2 가지 이점이 있습니다 :

1. 캐시가 뜨거우면 PHP가 실행되지 않습니다. 이렇게하면 시간과 메모리를 절약 할 수 있습니다.
2. 파일이 자주 요청되고 파일 크기가 충분하거나 RAM이 많은 경우 RAM에 저장됩니다. 이것은 MySQL보다 훨씬 빠릅니다.

Answer 3

다음

select page from (select * from cache where HASHEDURL = STOREDHASH) where url = 'someurl'