Update README.md

README.md

@@ -396,5 +396,4 @@ where ..
 ### 잠재적 문제 & 한계
 - 실제 서비스를 하게 된다면 검색 결과들의 분포가 어떤 특성을 가지게 될지 어려웠습니다.  테이블 크기의 30% 이상의 해당하는 결과를 검색하는 일이 더 잦다면, 오히려 like%word% 방식이 좋을 수도 있습니다.
   - 다만, **검색 결과가 0건인 최악의 경우(6초이상)** 보다는 평균적으로 1~2초내에 검색이 가능한 방식이라는 점에서 좀 더 자연스러운 최선의 방법이라 생각하였습니다.
-- fulltext-search의 결과는 메모리에서 처리됩니다. 테이블 데이터 200만건 기준으로 "FTS query exceeds result cache limit" 문제가 발생해 innodb_ft_result_cache_limit의 최대값을 4GB로 설정해두어 해결했지만, 만약 테이블의 크기가 더 커진다면 어느순간 같은  오류가 발생해 한계점이 올것입니다.
-- 테이블 데이터 200만건 기준 검색결과에 해당하는 로우가 절반이 넘어가는 시점부터 like %word% 의 table full scan보다 느린 분기점이 발생합니다.  
+- 테이블 데이터 200만건 기준 검색결과에 해당하는 로우의 비율이 50% 넘어가는 시점부터 like %word% 의 table full scan보다 느린 분기점이 발생합니다.