몇 바이트보다 긴 키 값을 가지는 경우, InnoDB 테이블의 기본 키 에 대해 자동 증가하는 숫자 컬럼을 사용하고 memcached의 키 값을 가진 컬럼에 고유의 보조 인덱스 를 만드는 것이 효율적인 경우 도 있습니다. 이것은 기본 키 값이 (자동 증가 값을 사용할 때처럼) 정렬 된 순서에 추가 될 경우 대규모 삽입 InnoDB 의 성능을 최대화하고 기본 키 값이 각 보조 인덱스 복제 된 기본 키가 긴 문자열 값의 경우에 불필요한 공간을 차지할 수 있기 때문입니다.

여러 가지 종류의 정보를 memcached에 저장할 때 데이터 유형에 대해 별도의 InnoDB 테이블을 설정할 수 있습니다. innodb_memcache.containers 테이블에 추가 테이블 식별자를 정의하고 @@ table_id . key 의 표기를 사용하여 항목을 다른 테이블에 저장하고 검색합니다. 항목을 물리적으로 분할하여 각 테이블의 특성을 조정하면 최적의 공간 활용, 성능 및 신뢰성을 얻을 수 있습니다. 예를 들어, 블로그 게시물을 보관하는 테이블에 압축 을 사용하여 썸네일 이미지를 유지하는 테이블을 사용하지 않을 수 있습니다. 매우 중요한 데이터가 유지되는 테이블은 다른 테이블보다 자주 백업하는 경우도 있습니다. SQL을 통해 보고서를 생성하기 위해 자주 사용되는 테이블에서 추가 보조 인덱스 를 작성하는 경우도 있습니다.

가능하면 memcached 인터페이스에서 사용하는 안정된 테이블 정의 세트를 설치하고 영구적으로 저장합니다. containers 테이블에 대한 변경은 테이블에 대해 쿼리가 다음 실행 때 사용됩니다. 그 테이블의 항목은 시작할 때 처리되어 인식되지 않은 테이블 ID가 @@ 표기 의해 요청 될 때마다 참조됩니다. 따라서 새 항목은 연결된 테이블 ID를 사용하려고하면 즉시 표시되지만 기존 항목에서 항목이 적용되기 전에 서버를 다시 시작해야합니다.

기본 캐시 정책 innodb_only 를 사용할 때 add() , set() , incr() 등의 호출은 성공하지만 while expecting 'STORED', got unexpected response 'NOT_STORED 등의 디버깅 메시지가 발생합니다. 이것은 innodb_only 구성에서는 새로운 값과 업데이트 된 값이 메모리 캐시에 저장되지 않고 InnoDB 테이블에 직접 전달되기 때문입니다.