Det finns lite du kan göra med den här frågan.
Prova detta:
-
Skapa en
PRIMARY KEY
påcategoryIds (categoryId)
-
Se till att
supplier (supplied_id)
är enPRIMARY KEY
-
Se till att
category_product (ProductID, CategoryID)
(i denna ordning) är enPRIMARY KEY
, eller så har du ett index medProductID
ledande.
-
Uppdatering:
Om det är INSERT
som orsakar problemet och product_search_query
i en MyISAM
tabell problemet kan vara med MyISAM
låsning.
MyISAM
låser hela tabellen om den bestämmer sig för att infoga en rad i ett ledigt block i mitten av tabellen vilket kan orsaka timeouts.
Testa att använda INSERT DELAYED
istället:
IF @resultsFound > 0 THEN
INSERT DELAYED INTO product_search_query (QueryText, CategoryId) VALUES (keywords, topLevelCategoryId);
END IF;
Detta kommer att placera posterna i insättningskön och återvända omedelbart. Posten kommer att läggas till senare asynkront.
Observera att du kan förlora information om servern dör efter att kommandot har utfärdats men innan posterna faktiskt har infogats.
Uppdatering:
Eftersom din tabell är InnoDB
, kan det vara ett problem med bordslåsning. INSERT DELAYED
stöds inte på InnoDB
.
Beroende på frågans karaktär, DML
frågor på InnoDB
bordet kan placera mellanrumslås som låser insatserna.
Till exempel:
CREATE TABLE t_lock (id INT NOT NULL PRIMARY KEY, val INT NOT NULL) ENGINE=InnoDB;
INSERT
INTO t_lock
VALUES
(1, 1),
(2, 2);
Den här frågan utför ref
skannar och placerar låsen på enskilda poster:
-- Session 1
START TRANSACTION;
UPDATE t_lock
SET val = 3
WHERE id IN (1, 2)
-- Session 2
START TRANSACTION;
INSERT
INTO t_lock
VALUES (3, 3)
-- Success
Den här frågan, samtidigt som den gör detsamma, utför ett range
skanna och placerar ett mellanrumslås efter nyckelvärdet 2
, som inte låter infoga nyckelvärdet 3
:
-- Session 1
START TRANSACTION;
UPDATE t_lock
SET val = 3
WHERE id BETWEEN 1 AND 2
-- Session 2
START TRANSACTION;
INSERT
INTO t_lock
VALUES (3, 3)
-- Locks