問題タブ [database-optimization]

この機能は次のように動作します。

• Web サイトにはユーザーがいて、ユーザーは任意の数の検索を保存できます (たとえば、NY の求人、PHP の求人など)。多くのパラメーターが関係しているため、これをインデックス化することは事実上不可能です (私は MySQL を使用しています)。
• 毎日多くの新しい求人がウェブサイトに掲載されます
• 24 時間ごとに、過去 24 時間以内に投稿された求人を取得し、それらを既存の求人検索と照合してから、一致する求人についてユーザーに電子メールで送信します。

ここでの問題は、トラフィックの多い Web サイトであり、楽観的なケース (新しい求人がほとんど掲載されていない) であっても、この検索クエリを実行するのに 10 分かかることです。この問題に対する古典的な解決策はありますか? 検索が集中する場所で Sphinx を使用してきましたが、ここでは適用できません。Sphinx はすべての結果を返すわけではなく、最終的にはそれらを切り捨ててしまうからです。今のところ、私ができる最善の方法は、search.matched_job_ids 列を用意し、求人が投稿されるたびに既存のすべての検索と照合し、一致した検索の Matched_job_ids 列に求人 ID を記録することです。一日の終わりに、ユーザーにメールを送信し、列を切り捨てます。これにより技術的にパフォーマンスが向上することはありませんが、1 つの大きなクエリではなく多数の小さな検索クエリを実行することで、時間の経過とともに負荷が分散されます。

MySQL の最適化について質問があります。market_transition1,000,000 データ行のテーブルがあるとします。SELECT * FROM market_transition WHERE end_time >= (SOME TIMESTAMP)実行すると 25,000 が返されるというパフォーマンス上の問題はありますか? 言い換えれば、select ステートメントが大量のデータ セットを返さなければならない場合、パフォーマンス上の問題はありますか? はいの場合、どのように最適化できますか? お手伝いありがとう。

私のデータベースには、 tablefileとtable がありますfile_content。fileテーブルには、 などのファイルのメタデータが格納さnameれますmime。はfile_content、ファイル コンテンツを含む BLOB を格納します。パフォーマンス上の理由から、ブロブをメタデータと同じテーブルに保存していません。

私のプロジェクトの「バージョン 2」については、Doctrine (2.3) を調べています。私にとって、「ファイル」は、次のように使用する必要がある 、 、 などのプロパティを持つ 1 つのエンティティのようnameですmime。extensioncontent

この動作は可能ですか? 私には、実際には 1 つのエンティティにすぎないものに対して 2 つのエンティティを作成することは意味がありません。ドキュメントでそれについて何も見つけることができず、Doctrine 2.1 では不可能であるという 2 年前のトピックを読みました: Doctrine 2.1 - Map entity to multiple tables

これを正しく処理する方法について何か提案はありますか? 私はDoctrineを初めて使用し、それが私のプロジェクトにとって正しい選択であるかどうかを確認するために少し遊んでいます。ありがとう。

低コストでデータベースからデータを取得する学校図書館を開発するための検索クエリを作成しようとしています。私のテーブルの中には、callNumber、author、title、およびyearがあります。請求番号、著者、タイトルから検索したい。

上記のクエリを使用しましたが、返されるデータは信頼できません。このクエリを最適化する際の提案または推奨事項は何でも。ありがとう

大規模なデータベースで構成される PHP Web プロジェクトを作成しようとしています。データベースは MYSQL になり、1 日あたり 30000 を超えるレコードが保存されます。DB を最適化するには、MEMCACHED ライブラリを使用すると考えました。私は正しい道を進んでいますか、それとも他の代替手段を使用してデータ最適化の問題を克服できますか。より高速な検索と挿入を提供したいだけです。データは徐々に高速で増加するため、どのツールをどのように使用すればよいか誰か教えてもらえますか? オブジェクト リレーショナル マッピングの概念も使用する必要がありますか?

データベース最適化のベスト プラクティスを提案できますか? これが私のデータベーススキーマです。

このスキーマには、スーパー管理者、企業ユーザー、エージェント ユーザー、エンド ユーザーの 4 種類のユーザー グループがあります。

各エンティティ（会社、エージェント）のユーザーを紹介する最良の方法は何ですか?

私には2つの選択肢があります

A. company_id および agent_id としての users テーブルの外部キー

B. company and agent テーブルの user_id としての外部キー

データベースとしてmysqlを使用し、カスケード参照を使用しています。会社/エージェントを削除すると、関連付けられたユーザーはオプション A に従って自動的に削除されます。ただし、オプション BI の場合、会社/エージェントの関連付けられたユーザーを削除するには、2 番目のクエリを実行する必要があります。それで、あなたは何を提案しますか？

更新: 子ユーザーについて言及するのを忘れていました。会社/エージェントのユーザーは、users テーブルの parent_id によって参照されるサブユーザーを持つことができます。

最適化の一環として、waiting for query cacheステップ中にどれくらいの時間が費やされたかを判断しようとしています。そのような集計値を取得することは可能ですか?

QuizMatches というテーブルを含むデータベースがあります。テーブルの構造は次のとおりです。

このテーブルには多数の行があり、複数のクライアントによって頻繁に使用されます。特に、次のようなクエリが実行されます。

主な問題は、データベースが完全なインデックス スキャンを実行することです。さまざまなインデックスの組み合わせを試しましたが、成功しませんでした。

上記の SELECT クエリで EXPLAIN を実行すると、次のメッセージが表示されます。

上記の例のように、このデータベース テーブルに対して SELECTS を最適化する方法はありますか?

ビュー内のテーブルにインデックスを追加すると、パフォーマンスが向上します。次のテーブルがあるとします。

車

• ID (pk)
• モデル
• オーナー

タイヤ

• ID (pk)
• 車ID
• サイズ

CAR_DETAILS (ビュー)

• 車ID
• オーナー
• モデル
• タイヤサイズ

ビューは CAR.ID=TYRES.CarID で結合されます。ここで、次のクエリが実行されたとします。SELECT model, tyreSize FROM CAR_DETAILS WHERE tyreSize=19; インデックス付きフィールドのビューをクエリしている場合、TIRES のインデックス サイズは役に立ちますか?