MySQL Heatwave выбрасывает ошибка 3877 при использовании regexp_substr, если не добавляется в фильтре. ⇐ MySql

[Anonymous]

Я работаю с MySQL 8.4.3-U12-Cloud в облачной инфраструктуре Oracle (OCI), используя двигатель Heatwave. У меня есть большая таблица (logs_audit) с около 70 миллионов строк (около 1 миллиона в день). Мне нужно извлечь код аудита из столбца log_detail. Форматом кода является xxxx-xxxx-xxxx-xxxx (только заглавные буквы и цифры). < /P>
Для извлечения последнего соответствующего кода (в случае, если есть несколько), я изменяю строку и использую regexp_substr: < /p>
SELECT
REVERSE(REGEXP_SUBSTR(REVERSE(log_detail), '([A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+)'))
FROM logs_audit
WHERE
operator = "WALMART"
AND registration_time >= '2025-07-22'
AND registration_time < '2025-07-23';
< /code>
Тем не менее, этот запрос не выполняет следующую ошибку:
SQL Error [3877] [HY000]: Regexp function error in HeatWave query execution, please check the expression syntax. < /code>
шаблон верен, и запрос работает отлично, если я добавляю дополнительный фильтр, такой как: < /p>
AND device_id NOT IN (SELECT id FROM internal_devices)
< /code>
или даже: < /p>
AND device_id IN (SELECT id FROM internal_devices)
< /code>
Это говорит о том, что проблема не связана с шаблоном повторного лечения или самих данных, а в том, как теплово -волна оптимизирует или оценивает запрос внутри. /> Обертывание режима с помощью случая, когда пункт < /p>
< /li>
Перемещение логики повторного лечения в подпрограмму, которая фильтровала log_detail, не является
null < /p>
< /li>
filetrait /> < /li>
< /ul>
Например, это также не удается: < /p>
SELECT
REVERSE(REGEXP_SUBSTR(REVERSE(log_detail), '[A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+'))
FROM (
SELECT log_detail
FROM logs_audit
WHERE
operator = "WALMART"
AND registration_time >= '2025-07-22'
AND registration_time < '2025-07-23'
AND log_detail IS NOT NULL
AND REVERSE(log_detail) REGEXP '[A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+-[A-Z0-9]+'
) AS sub;
< /code>
Странная часть: запрос работает только в том случае, если я добавляю дополнительное условие, такое как Device_id в (...) или нет в (...), даже если этот столбец не имеет отношения к содержанию log_detail. Почему REGEXP_SUBSTR ТИГЕРСКИЙ ОШИБКА 3877, если не добавляется дополнительный не связанный фильтр? Есть ли надежный, задокументированный способ безопасного применения Regex на больших таблицах в тепловой волне без столкновения с этой проблемой? Самая длинная строка в этом столбце составляет приблизительно 4008 символов. Несмотря на большой размер некоторых строк, ошибка постоянно возникает, если не применяется дополнительная в/не в фильтре. Это говорит о том, что проблема не просто связана с длиной строки, но, возможно, как тепловая обработка обработки рецидивов REGEX по определенным рядам.

Подробнее здесь: https://stackoverflow.com/questions/797 ... -not-in-fi