0

合計で約 150,000 レコード (名前) の mysql データベースを使用しています。「names」フィールドでの検索は、php のオートコンプリート機能を介して行われます。テーブルにインデックスを付けましたが、検索が少し遅いように感じます (ほぼ瞬時に応答する Google Finance のようなものに対して、数秒かかります)。私たちは 2 つの可能性を考え出しましたが、より多くの洞察を得たかったのです。

  1. 検索を高速化するために大量の (数千またはそれ以上の) ストアド プロシージャを作成できますか? それとも、それほど多くのストアド プロシージャを作成するとデータベースの速度が低下しますか?

  2. 「select」ステートメントのmysqlに代わるより高速な方法はありますか（行の挿入と更新の速度はそれほど重要ではないため、必要に応じて犠牲にすることができます）。JOIN ステートメントをサポートしていない BigTable などについて漠然と聞いたことがあります....私たちが行う他のクエリのいくつかには JOIN ステートメントが必要です。

どうも

4

3 に答える 3

1
  1. ストアド プロシージャのことは忘れてください。彼らはあなたのために何の役にも立ちません。
  2. Mysql は良い選択です。多くの場合、最速の RDBMS と見なされています。また、「select ステートメントのより高速な代替手段」を探す必要はありません。

あなたが言及した異常なクエリ実行時間は、サーバーの構成ミスまたはデータベーススキーマの誤り、またはその両方の結果です。serverfault に関するこの回答を読むか、ここで質問を更新してください: サーバー構成、データベース スキーマの一部、および問題のクエリを提供します。explain select ...

于 2011-01-18T09:02:38.620 に答える
0

データベースへの呼び出しが繰り返されないように、情報をメモリにキャッシュする必要があります。

于 2011-01-18T00:56:29.373 に答える
0

はい、データを変更する場合はキャッシュを期限切れにする必要がありますが、あなたが言ったように、それは一般的ではないため、半自動で行うこともでき、必要に応じて心配する必要はありません。この MySQL.com の記事をチェックして、おそらく MEMORY ストレージ エンジン (申し訳ありませんが、新しいもので、投稿ごとに複数のハイパーリンクを投稿することはできませんか?!) を調べてください。非常に効率的です。

実際のクエリ時間 (対ページ時間) は? 地獄にロードされていない合理的に最新のサーバーでは、MySQL は 15 万行のオートコンプリート クエリを 2 秒よりもはるかに高速に実行できるはずです。いくつかのインデックスがありませんか?

于 2011-01-18T02:33:34.750 に答える