MySQLストアドプロシージャが問題を引き起こしていますか？

このクエリでできることはほとんどありません。

これを試してください：

PRIMARY KEYを作成します categoryIds (categoryId)
- supplier (supplied_id) PRIMARY KEYです
- category_product (ProductID, CategoryID)であることを確認してください（この順序で）はPRIMARY KEY 、またはProductIDのインデックスがありますリーディング。

更新：

INSERTの場合それが問題を引き起こし、product_search_query MyISAMでテーブル問題はMyISAMで発生する可能性がありますロックします。

MyISAM テーブルの中央にある空きブロックに行を挿入することを決定した場合、テーブル全体をロックします。これにより、タイムアウトが発生する可能性があります。

INSERT DELAYEDを使用してみてください代わりに：

IF @resultsFound > 0 THEN
    INSERT DELAYED INTO product_search_query (QueryText, CategoryId) VALUES (keywords, topLevelCategoryId);
END IF;

これにより、レコードが挿入キューに入れられ、すぐに返されます。レコードは後で非同期的に追加されます。

コマンドが発行された後、レコードが実際に挿入される前にサーバーが停止すると、情報が失われる可能性があることに注意してください。

更新：

テーブルはInnoDBなので、テーブルのロックに問題がある可能性があります。 INSERT DELAYED InnoDBではサポートされていません。

クエリの性質に応じて、DML InnoDBでのクエリテーブルは、インサートをロックするギャップロックを配置する場合があります。

例：

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);

このクエリはrefを実行しますスキャンして個々のレコードにロックを設定します：

-- 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

このクエリは、同じことをしながら、rangeを実行しますキー値2の後にギャップロックをスキャンして配置します、キー値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