（下手な英語を許してください）
特定の範囲の URL でカスタム Web クローラーを操作しています。私はそれをテストしており、これまでのところすべてが完璧に機能しています..
最近、議論したいパフォーマンスの問題に気づきました。ボットは、url_pool テーブルでインデックス付けされたページをクロールしています。ターゲット ページでターゲット コンテンツを検索している間、ボットは、テーブルにない場合は見つけたページ リンクを保存します。すでに...いくつかのクロールスクリプトを（同時に）操作しているときに競合の問題が発生しましたが、修正しました。
約 150 万ページをクロールした後、私の url_pool テーブルには、URL、いくつかの「フラグ」、URL ハッシュ (32 桁の simhash)、ドメインなどを含むほぼ 500 万行が含まれています...
mysql db テーブルは、大きなバッファを備えた innodb であり、検索クエリに従って適切にインデックス化されています。ボットのパフォーマンスを監視しているときに、テーブル内の URL の重複を防ぐために使用する「存在するかどうかを確認する」機能がますます遅くなっていることに気付きました。テーブルが大きくなるほど検索に時間がかかることは明らかですが、実行時間の増加を確認するには時期尚早のようです。
パフォーマンスを要約すると：
- url_pool~100K ROWS -> クロール プロセス全体で 0.8 秒 (1 ページ)。
- url_pool~800K 行 -> 1.1 秒
- url_pool~1.8M 行 -> 1.9 秒
- url_pool~3.5M 行 -> 3.2 秒
- url_pool~5M 行 -> 4.8 秒
もう1つの重要な事実は、テキストを使用して検索するのではなく、テーブルにURLが存在するかどうかを確認しながら、ハッシュを作成し、それをテーブル内の他のものと照合していることです。クローラーを構築する初期段階で受け取ったアドバイスに従いました、パフォーマンスが向上することがわかりました。
現在、各ページの 1.9 秒は運賃ですが (4 つのボットを一緒に実行することを考えると)、5 秒では遅すぎます....
アドバイスをお願いできますか？
編集：
いくつかの詳細情報:
私は使用します：
SELECT EXISTS(SELECT 1 FROM table1 WHERE ...)
インデックス付きの列に対する検索クエリ（ドキュメントでは、結果を高速化するために推奨されています）の場合、テーブル構造は非常に単純なテーブルです
ID
リンク (varchar 400)
link_simhash (varchar 32)
ドメイン (varchar 200)
フラグ 1 (ブール値)
フラグ 2 (ボール)
bot_visit (int)
date_found (日付)
date_crawled (日付)
私が言ったように、場所はリンクハッシュを参照しています。
何か案は？？？誰でもない？？？私の質問の何が問題なのですか？