Hello Andrey,

There is some good news for you!
After using multiple technologies and conducting continuous research for the past 8 hours, I have identified and implemented a solution. Please ask your server team to check it again and share their feedback .

1.
Issue: Every time a customer viewed a single phone number, the server was forced to scan all 594,000+ numbers twice, running a heavy mathematical formula row-by-row. This single feature was taking up to 10 minutes per page view and choking the server.
Fixed: Completely modernized and rewritten the “Similar Numbers” widget. Instead of forcing the database to perform 1.2 million heavy calculations per view, it now uses instant database lookups and calculates matches in computer memory.

2.
Issue:Several large database tables (including product reservations and session tables) had no indexes, forcing the database to scan tens of thousands of rows on basic lookups.
Fixed:Optimized category queries to use direct relationships instead of slow comma-separated text searches.

3.
Issue:Multiple active tables were locking the entire table every time a visitor performed a search or visited a page, queuing up other customers.
Fixed:Prepared clean indexing scripts and converted high-traffic tables to InnoDB (row-level locking), allowing multiple customers to shop simultaneously without waiting.

There is one table that I am unable to handle and convert to InnoDB (cart_product_related_byviews). Please ask the server team to convert it to InnoDB by running the following query:
ALTER TABLE cart_product_related_byviews ENGINE=InnoDB;
Also, please delete data older than 6 months from this table.