Yes. It’s one query, and it’s not close.
The query breaking your server:
sql

SELECT p.*, pi.*
FROM cart_products p
LEFT JOIN cart_product_images pi
ON (p.productid = pi.imageprodid AND pi.imageisthumb = 1)
WHERE p.prodvisible = 1
AND productid != 98898
AND FIND_IN_SET(78, prodcatids)
AND prodavailability = ‘unreserved’
AND prodcurrentinv != 0
AND levenshtein_ratio(‘(813) 896-2999’, prodname) > 60
ORDER BY levenshtein_ratio(‘(813) 896-2999’, prodname) DESC
LIMIT 5;

Run by database user excellen_shaz on schema excellen_vip3. It’s the “similar phone numbers” widget on your product detail pages — it fires once per product page view.
What it did on 09-09-2026:

Executions

9,531 of 9,783 in the log
Share of all database time

99.88%
Total time consumed

5,600,935s = 1,556 hours in one day
Rows examined per run

594,007
Rows returned per run

5
Average runtime

588s
Worst single run

6,406s — 1 hour 47 minutes
The worst five executions of the day, all this same query:
Started

Ended

Duration

Thread
06:10:13

07:56:59

107 min

56412
05:30:32

07:16:35

106 min

54410
05:29:42

07:13:55

104 min

54364
05:59:58

07:43:51

104 min

55765
06:52:34

08:31:01

98 min

58620
229 executions ran longer than an hour. 2,096 ran longer than ten minutes. All of them this query.
Why it kills the server specifically:
The levenshtein_ratio() user-defined function has to be computed on every single one of the 594,007 rows — and then a second time for the ORDER BY. That’s roughly 1.2 million UDF calls per execution, each one pure CPU with no index able to skip a single row. FIND_IN_SET(78, prodcatids) guarantees the full scan on its own, since categories are stored as a comma-separated string.
The mechanism that turns a slow query into an outage is the pile-up. Each page view starts a new copy. At peak you had 218 running at once, each burning CPU on 1.2 million function calls. They starve each other, so each one gets slower, so more accumulate. Average concurrency across the whole 24 hours was 65.9 and it never dropped below 19.
Two pieces of evidence confirm the query itself is the cause rather than a victim of general server load:

The isolated manual run by user excellentnumbers — same query, run by hand with far less contention — still took 98 seconds.
Three executions examined zero rows and still averaged 859 seconds. They weren’t doing work; they were queued for CPU that never came. That’s starvation caused by the other copies.

The single fastest thing you can do right now is SET GLOBAL max_statement_time = 30;. It doesn’t fix the query, but it makes it impossible for one to run for 107 minutes, and it would have killed all 229 of the hour-long executions before they could stack up.