Organizing the tag system

Hello everyone. An order has been received, in fact it boils down to a banal network of articles with a search for onlytags. The catch is that they promise over 9000 visits and several million entries, in connection with which the request is of the form

SELECT [...] WHERE tags LIKE %tag1*tag2%

seems unacceptable. So far, I’m only thinking about creating a table of tags with IDs and a table with cross-references [tagID, articleID], but here I’m afraid to run into the volume of the latter – a record can have several tens, or even hundreds, of tag characteristics. Also take into account sequential search (click-view-click-view, etc.)

Actually, who can advise what?
// yes, the hashcode has a similar system – imagine ten million questions with 30-200 tags each.

Answer 1, authority 100%

it looks like this:
store tags in a separate table in the same way as for a small site.
and to display on the site not real-time requests, but to prepare first.
This cache can be recalculated only when adding an article.
add an article and recalculate only those tags that are in it.