問題タブ [database-optimization]

私はメッセージ ボードを作成しており、通常のトピック (つまり、貼り付けられていないトピック) を取得して、最後に投稿されたメッセージの日付で並べ替えようとしています。これを達成することはできますが、約 10,000 件のメッセージと 1500 件のトピックがある場合、クエリ時間は 60 秒を超えます。

私の質問は、パフォーマンスを向上させるためにクエリにできることはありますか、それとも設計に根本的な欠陥がありますか?

これが私が使用しているクエリです。

編集ここに説明計画があります

インデックス

帯域幅と全体的な効率の点で、どのオプションが最も高価か知りたいです。

アプリケーションにクラスClientがあり、データベースにテーブルがあるとclientします。

Client.getByIdクライアントレコード全体を取得する静的関数を1つ持つか、個々のフィールドを取得する多数（、など）を使用する方がよいClient.getNameByIdでしょClient.getMobileNumberByIdうか。

1つのレコードに多くのフィールドがあり、現在のスクリプトで1つまたは2つを使用することになった場合でも、すべてを取得して、アプリケーション内ですべてのデータをどのように処理するかを決定する方がよいでしょうか。

ちなみに私はPHPとMySQLを使っています。

私のテーブルに含める方法についてあなたの助けが必要です INDEXES、私はそれについていくつかのチュートリアルで読みましたが、それでも私のデータベースにそれを実装することはできません。データベースの効率を上げるために：私はwampserverにインストールしましたが、少し高速です。また、必要に応じてクエリでphp_apc.dllの使用を避けようとしました 。SELECT * しかし、どのように実装するか INDEXが私の問題です。どこが必要か教えていただければ幸いINDEXです。

これが私のデータベーススキーマです

私のクエリのほとんどは、 INSERTINTO MAINTABLE、 STUDENTS.....、 SELECTFROM MAINTABLE、 STUDENTSおよびCOURSES

ご理解とご協力のほどよろしくお願いいたします。とても感謝しています。ありがとう。

**クエリの例」

私のフォーマットを許してください。携帯から入力しました。お時間をいただきありがとうございます。

次のような方法でエンティティ (たとえばuser ) を複数のテーブルに分散するのはなぜですか。

この DB 設計から得られるスピードアップ ボーナスはありますか? 連鎖結合を実行してデータを取得することは、選択プロジェクションを使用するよりも計り知れないほど悪いように思われるため、非常に直感に反します..

もちろん、user_id とユーザー名のみを使用して他のクエリを実行すると、速度が向上しますが、それだけの価値があるでしょうか? では、真の利点はどこにあり、そのような DB 設計戦略に適した互換性のある作業シナリオは何でしょうか?

後の編集:この投稿の詳細では、属性が量的に変化しない完全で一意のエンティティを想定してください (たとえば、車の色は 2 つではなく 1 つだけであり、ユーザーはユーザー名/社会的秒番号/入学番号を 1 つだけ持っています)。 /home address/email/etc.. つまり、1 対多の関係ではなく、1 対 1 の完全に一貫したエンティティの説明を扱っています。上の例では、これがまさにそのケースです。単一のテーブルが、それが持っていた非主キー列と同じ数のテーブルに「分割」されています。

速度が重要な予測ダイヤラーを構築しています。番号をダイヤルするには、テーブルから顧客情報を取得し、pbx が処理する呼び出しファイルを作成します。

現在は市外局番ごとに表を作っており、市外局番ごとにダイヤルしていますが、複数の郵便番号にまたがる地域ごとにダイヤルするモデルに切り替えています。一部の市外局番は、複数の郵便番号に存在します。各テーブルには毎月新しい番号が追加され、数百万の番号の通話禁止リストと比較してスクラブされます。

私の質問は、このデータを最も効率的に整理するにはどうすればよいですか?

スクラブされたデータの何百万ものレコードについて話しているので、1 つの大きなテーブルは非生産的です。

私の現在の推論は、インポートとスクラブのために市外局番テーブルを維持し、スクラブされたレコードを地域テーブルにコピーすることです。このテーブルは、市外局番テーブルでその地域の郵便番号を検索することによって作成されます。

私は現在、auto_incremented INT プライマリ キー、一意の電話番号、および既に呼び出された番号または発信禁止リストにある番号を追跡するステータスによって、テーブルのインデックスを作成しています。通話ファイルを作成するときは、レコードをキューに登録済みとしてマークし、完了した通話の進行状況に応じてマークを付けます。そのため、通話ごとに検索と 2 回の更新が行われます。

検索では、市外局番テーブルで特定のステータスが検索されます。更新は、レコード ID に基づいて行われます。

質問の要点は次のとおりです。郵便番号で整理してステータスで検索するか、市外局番で整理してステータスと郵便番号で検索する方が速いでしょうか? それとも、市外局番テーブルから構築された地域を設定するたびに、新しいテーブルを作成する方がよいでしょうか?

これがばかげた質問のように思われる場合は、ご容赦ください。私はこれを構築しているときに SQL を独学してきました。データベースの設計とパフォーマンスのニュアンスは、私のスキルセットを少し超えています。

テーブルの合計サイズは 200 万行で、さらに増え続けています。

次のようcountsな列を含むテーブルがあります（約14カウント列）：

このテーブルは、ユーザーが写真や友達を追加するたびに更新されます。

行をロックする方が良いので、InnoDB Engineを使用しますが、それまでの間、このテーブルにはかなりの数の読み取りがあります。他のユーザーのプロファイルが表示されたとき、またはユーザー側のメニューにこれらすべてのカウントが含まれているときは、すべてのユーザーに対して。

このようなほとんどの書き込みとほとんどの読み取りに最適なエンジンはどれですか？

まず、SQLServerのインデックスに関する知識があまりないことを指摘しておきます。

私の状況では、通常は大量のテキストで満たされたvarchar（max）列を持つSQLServer2008データベーステーブルがあります。

私のASP.NETWebアプリケーションには、キーワード検索のためにこの列をクエリする検索機能があり、検索されるキーワードの数に応じて、SQLクエリ内の1つまたは複数のLIKE'％keyword％'ステートメントで検索を実行できます。

私のWebアプリケーションでは、このテーブルの1つの列だけでなく、他のさまざまな列でも検索できます。他のテーブルからの結合もいくつかあります。

私の質問は、これらの検索クエリのパフォーマンスを向上させるために、この列にインデックスを作成する価値がありますか？もしそうなら、どのタイプのインデックスで、1つの列にインデックスを付けるだけで十分ですか、それとも主キーや他の検索可能な列などの他の列を含める必要がありますか？

データベースとの接続の量を最小限に抑える方がよいため (特にネットワーク トラフィックが激しい状況では)、効率の観点からは、多数の小さなクエリよりも 1 つの大きなクエリを使用する方がよいことを知っています。

私の質問は、一連のデータベース操作を分離して原子化する (そして、そのうちの 1 つが失敗した場合にロールバックを行う) 以外に、トランザクションは大きなクエリのように振る舞うのでしょうか? つまり、多くのデータベース操作を行う必要がある場合、それをトランザクションにラップして、1 つの大きな操作に変えることはできますか?

テーブルがSiteありContent、データベースに含まれています。

各サイトは異なるクライアントによって運営されており、各サイトには独自のコンテンツがあります。

サイトのフロント エンドでは、コンテンツ テーブルで全文/フリーテキスト検索を使用して結果を返す検索ボックスを提供していますが、各サイトはデータベース内の他のサイトからではなく、それ自体からのみ結果を返すことができます。

ここでは、SQL Server クエリ オプティマイザーの動作が適切ではありません。コンテンツの少ないサイトのクエリを最適化すると、コンテンツの多いサイトのクエリはひどく実行され、タイムアウトが発生します。

これを修正するためにクエリの最後に追加できることは理解してOPTION(RECOMPILE)いますが、私の質問はこれです...

サイトごとにキャッシュ テーブルを作成して、各サイトのコンテンツを定期的にキャッシュし、パラメーターを使用する代わりに検索ストアド プロシージャでキャッシュ テーブルを検索できるようにする方がよいでしょうか?

キャッシュは、コンテンツが追加/変更されるたびにのみ更新/更新されます。

私の考えでは、これは....

a) 検索対象のテーブルのサイズを縮小して、正しいサイトのレコードのみが含まれるようにします

b) 全文検索で各サイトのコンテンツのより正確なインデックスを生成できるようにする

c) クエリ オプティマイザが各サイトの最適化されたクエリを個別にキャッシュできるようにする

これは正しいです？このようにするのは正しいですか？

夜、

私は、使い古された 15 年前の読み取り専用データ形式からデータを MySQL にインポートして、そこからいくつかの小さな統計テーブルを作成するという長いプロセスを経ています。

私が以前に構築した最大のテーブルは (私が思うに) 3,200 万行でしたが、これほど大きくなるとは思っていなかったので、MySQL にかなり負担をかけていました。

テーブルは次のようになります。

したがって、小さな int と varchar です。

これをできるだけ早く機能させる方法について誰かアドバイスをいただけますか? いずれかの列のインデックスが役立つか、クエリが遅くなるだけです。

各列のデータの多くは、何度も複製されます。一部のフィールドには、約 100 を超える異なる値がありません。

テーブルを照会する主な列は、姓、名前、rco、rplace です。