optimize_or_like_chain
OR LIKE/ILIKE/match 프레디케이트를 단일 multiSearchAny/multiSearchAnyCaseInsensitiveUTF8(순수 부분 문자열 %needle% 패턴의 경우) 또는 multiMatchAny(기타 패턴의 경우, Hyperscan/Vectorscan이 허용되면)로 최적화합니다. 어느 쪽의 빠른 경로도 적용할 수 없는 경우 — 예를 들어 Hyperscan이 비활성화되어 있거나 사용할 수 없거나, 패턴이 원시 match 정규식이거나, 유효한 UTF-8이 아니거나, 내장 NUL을 포함하거나, haystack이 FixedString/Enum인 경우 — 결합된 match 교대식이 RE2에서는 원래의 단락 평가 OR보다 일관되게 느리므로 원래 OR 체인을 변경 없이 유지합니다.
이 최적화는 분석기(enable_analyzer = 1, 기본값)를 사용할 때만 적용됩니다. 이전 분석기(enable_analyzer = 0)에서는 OR 체인을 변경하지 않습니다. 순수한 LIKE/ILIKE/match OR 체인의 경우 인덱스 분석이 가능하도록 원래 표현식을 indexHint()에 보존합니다. LIKE가 아닌 분기를 포함하는 혼합 OR 체인은 LIKE가 아닌 분기에만 일치하는 범위까지 프루닝되지 않도록 의도적으로 indexHint() 래핑을 적용하지 않습니다. multiMatchAny 재작성은 allow_hyperscan, max_hyperscan_regexp_length, max_hyperscan_regexp_total_length, reject_expensive_hyperscan_regexps를 따릅니다.
체인은 동일한 좌변 표현식을 공유하는 분기가 충분히 많아 재작성이 단락 평가 OR보다 확실히 더 빠르다고 판단될 때만 재작성됩니다. multiSearchAny 경로에는 최소 optimize_or_like_chain_min_substrings개의 분기가 필요하고, multiMatchAny 경로에는 최소 optimize_or_like_chain_min_patterns개의 분기가 필요합니다.
optimize_or_like_chain_min_patterns
LIKE/ILIKE/match 분기(prefix/suffix/regexp 패턴)가 optimize_or_like_chain에 의해 체인에서 multiMatchAny로 재작성되기 위해 필요한 최소 개수입니다. hits 데이터셋을 기준으로 보정되었습니다(tests/performance/optimize_or_like_chain_hits.xml 참조). prefix/regexp LIKE 체인에 대한 multiMatchAny(Hyperscan) 재작성은 대략 9개의 분기부터만 단락 평가 OR 평가보다 빨라지므로, 더 짧은 체인은 성능 저하를 피하기 위해 그대로 유지됩니다. 값이 0 또는 1이면 이 임계값이 비활성화됩니다. optimize_or_like_chain이 비활성화된 경우에는 영향을 주지 않습니다. 순수 부분 문자열(multiSearchAny) 경로는 optimize_or_like_chain_min_substrings도 참조하십시오.
optimize_or_like_chain_min_substrings
%needle%) LIKE/ILIKE 분기를 optimize_or_like_chain이 multiSearchAny/multiSearchAnyCaseInsensitiveUTF8로 재작성하려면 필요한 최소 개수입니다. hits 데이터셋(tests/performance/optimize_or_like_chain_hits.xml 참조)을 기준으로 조정한 결과, 대략 4개의 분기부터 multiSearchAny 재작성이 단락 OR 평가보다 더 빨라집니다. 값이 0 또는 1이면 이 임계값이 비활성화됩니다. optimize_or_like_chain이 비활성화되어 있으면 효과가 없습니다. regexp(multiMatchAny) 경로는 optimize_or_like_chain_min_patterns도 참조하십시오.