How to do a SQL regular expression search?

Question

MySQL

SELECT * FROM `post` WHERE `description` REGEXP 'itemid=34543[^\d]*'

I want to find such a value itemid = 34543 after that, anything but numbers, but for some reason it gives out something wrong, tell me how to use everything except in sql

Answer 1

You have 2 main approaches
1. through 2 expressions using the operators listed here
https://dev.mysql.com/doc/refman/8.0/en/regexp.html
Maybe not all in any combination, but it is essential that one operator should find part of a sequence of characters that should be answered, e.g.
SELECT *
FROM `post`
WHERE
-- 1st expression
`description` LIKE 'itemid=34543%'
-- 2nd expression
AND
`description` NOT RLIKE 'itemid=34543 [0-9]+'
2. through 1 regular expression, very similar to the one you suggested, but apparently with a \ ( backslash ) character followed twice, the same page explains why: "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."
If, for one reason or another, the expression balks, you can probably use the expression one character longer to express the numbers [^0-9]
Well, you should probably use the plus, and not the asterisk on the right [^0-9]+, otherwise this part becomes optional, and the query can choose, for example, the value 'itemid=34543'
---
Good luck!

Answer 2

TL;DR: rewrite the database before it's too late. Bring it into 3 normal form and you will be "happiness".
1) Storing the data for which the search is being carried out in this form is to immediately sign in your prof. unfitness, do not show this shame to anyone.
2) Spread the data normally across the tables, don't think that you just "got out" by putting everything into a string and everything is in chocolate. Nifiga, now you will have terribly slow requests for this field, since the slowest operations are like and regexp. Especially on the field with a variable long and without normal indexes. And all this instead of a super-fast index on an integer field.
3) In addition to other problems - now instead of just updating the field, you first need to calculate it, parse it and only then update it so as not to lose information, that is, you transfer part of the standard database logic to the code where it does not belong.
4) well, you have already run into one of the problems - a search for fuzzy data will give a fuzzy result.