MySQL имеет значительно более слабая поддержка выполнения запросов
Вплоть до 5.7 не имел процедур.
Хотя структуры языка позволяющие создать процедуры у MySQL после этого появились, как такового языка программирования, выполнения логических операций, у MySQL не существовало. Возможно это изменилось. Но скорее нет.
Таким образом называть MySQL полноценной СУБД нельзя.
Если кого - то возможно не смущает создание кластеризованных индексов "по умолчанию", то для меня отсутствие подобных рычагов управления верстки цифровых записей неприемлемы.
----
PosgreSQL база совершенно иного уровня, в плане академических требований, но вплоть до 9-й версии страдала от файл-объектной структуры записи, то есть каждая таблица или индекс это свой файл. Неизбежным результатом оказались провалы в аккуратности учета данных, когда от базы потребовались решения сверхзадач. Передача файловой системе ОС ответственности за аккуратность учета операций записи привели к потере самой базой доверия пользователя ( Uber ).
Ситуация была выправлена в авральном порядке, и теперь у PostgreSQL все в полном порядке. Костяк команды разработчиков сумел быстро поправить ситуацию через несгибаемую волю и удивительный профессионализм ( как нам всем сейчас этого в России не хватает после того, как это было в избытке в советское время ).
Поэтому с PostgreSQL на сегодня вопрос конечно не простой. Но и здесь, конечно, базе, которую поддерживают исключительными личными жертвами группа волевых и компетентных соратников, трудно тягаться с коллективом у которого есть цель, план развития, и видение изнутри всего многообразия цифровой индустрии.
Ни у одной базы никогда не будет возможности похвастаться полноценной и постоянно улучшающейся поддержки очередей, встроенных каталогов интеграции данных, отдельная но хорошо отлаженная для совместной работы на сервере службы OLAP, и полноценного ядра обработки данных непосредственно в памяти резидента выполнимого ( Hecaton ). Плюс разнообразные форматы хранения данных, безупречная поддержка языков и кодирования символов, c SQL Server трудно состязаться. А возможность запросто вскрыть протокол общения и просмотреть запросы выполненные базой через profiler делают работу как разработчика, так и службы поддержки простой и легко поддающейся уму человека, у которого есть семья, дети, родители, и что - то в жизни, кроме работы.
----
Я писал этот пост и уже тогда подумал, что MySQL и PostgreSQL не полный выбор из возможного списка конкурентов SQL Server на место СУБД. Меня, в свое время, заинтересовал Линтер. Раньше эта СУБД считалась русской, но в 2015-м - 17-м проскользнули данные о выкупе продукта зарубежными гражданами. Оставив темную историю с правами на продукт в стороне, по моим оценкам у базы есть все необходимые качества для обслуживания цифрового предприятия.
Возможно там есть ограничения по количеству потоков, объему хранимых данных. Это наверное надо проверить с поставщиком.
Поиск и оценку русских продуктов СУБД я веду непрерывно, и буду благодарен за любые подсказки и указатели.

Один мудрый индийский рекрутер поделился со мной аббревиатурой TOGAF, а всё остальное я нашел сам.
Надеюсь Вам тоже поможет.
Не самое важное, на мой скромный взгляд вопрос тянет на уровень сложности средний.

У Вас есть 2 основных подхода
1. через 2 выражения пользуясь операторами перечисленными здесь
https://dev.mysql.com/doc/refman/8.0/en/regexp.html
Возможно не всеми в любой комбинации, но существенно то, что один оператор должен найти часть последовательности символов, которые должны ответить, например
SELECT *
FROM `post`
WHERE
-- 1-е выражение
`description` LIKE 'itemid=34543%'
-- 2-е выражение
AND
`description` NOT RLIKE 'itemid=34543[0-9]+'

2. через 1 регулярное выражение, очень похожее на то, которое Вы предложили, но видимо с \ ( backslash ) символом проведенным дважды, на той же странице объясняется почему: "Because MySQL uses the C escape syntax in strings (for example, \n to represent the newline character), you must double any \ that you use in your expr and pat arguments."
Если по той или иной причине выражение артачится, наверное можно воспользоваться выражением на один символ длиннее, для выражения цифр [^0-9]
Ну и наверное надо воспользоваться плюсом, а не звездочкой справа [^0-9]+, иначе эта часть становится не обязательной, и запрос может выбрать, например, значение 'itemid=34543'
---
Всего хорошего!