MySQLのパフォーマンス - 大きなテーブルからの選択と削除

Question

"queue"という大きなテーブルがあります。今は1200万レコードあります。

CREATE TABLE `queue` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `userid` varchar(64) DEFAULT NULL, 
    `action` varchar(32) DEFAULT NULL, 
    `target` varchar(64) DEFAULT NULL, 
    `name` varchar(64) DEFAULT NULL, 
    `state` int(11) DEFAULT '0', 
    `timestamp` int(11) DEFAULT '0', 
    `errors` int(11) DEFAULT '0', 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `idx_unique` (`userid`,`action`,`target`), 
    KEY `idx_userid` (`userid`), 
    KEY `idx_state` (`state`) 
) ENGINE=InnoDB; 

複数PHP労働者（150）は、同時に、このテーブルを使用します。

レコードを選択し、選択したデータを使用してネットワーク要求を実行し、レコードを削除します。

selectクエリとdeleteクエリから実行時間が混在しています。 deleteコマンドはテーブルをロックしていますか？

このシナリオにはどのようなアプローチが最適でしょうか？

1. 記録+ NETWORK要求は+記録に

2. を削除]を選択し完了として（私もしたくない時からのcronを使用して完成したレコードをDELETE +記録+ NETWORK要求+ MARKレコードを選択大きなテーブル）。

注：キューは1分ごとに新しいレコードを取得しますが、INSERTクエリはここでは問題になりません。

何か助けていただければ幸いです。

Answer 1

「キューに入れないで、やってください」つまり、タスクがかなり速い場合は、単にアクションを実行し、キューに入れないほうがよいでしょう。データベースは良い待ち行列メカニズムを作っていません。

DELETE InnoDBテーブルをロックしません。しかし、あなたはDELETEと書くことはできません。あなたの実際のSQLを見て、それを改善するために働くことができます。

12Mレコード？それは大きなバックログです。どうしたの？

表がギガバイトにならないようにデータ型を縮小します。

• actionは、可能な値のわずかなセットですか！これを1バイトのENUMまたはTINYINT UNSIGNEDに正規化します。
• 同上state - 確かに4バイトコードは必要ありませんか？
• すでにuseridで始まるインデックス（UNIQUE）があるので、INDEX(userid)の必要はありません。
• stateの値がわずかである場合、インデックスは使用されません。エンキューとデキューのクエリを見て、そのインデックスを取り除く方法と、そのインデックスを「合成」する（有用な）方法について話し合うことができます。
• MAX(id)の現在の値は何ですか？それはINT UNSIGNEDの約40億のあなたの現在の限界を超えることを脅かすのですか？
• PHPはどのようにキューを使用しますか？ InnoDBトランザクションを介してアイテムにハングアップしますか？これはどんな並列性にも勝るものです！または、それはstateに変更されますか？コードを見せてください。おそらくロック&のロックを解除することができます低侵襲。 1つの自動コミットされたUPDATEを実行して行を取得し、idを実行することが可能でなければなりません。それから、後で自動コミットされたDELETEを実行してください。
• 保留中のアイテムを取得するための良好なインデックスはありません。もう一度、コードを見てみましょう。
• 150は多くのように思われます - を少し実験しました？彼らはかもしれないはお互いにつまずいている。
• スローログが有効になっていますか（long_query_timeの値が小さい）？もしそうなら、私は「最悪の」クエリが何であるか疑問に思います。このような状況では、その答えは驚くかもしれません。