MySQLのクエリのパフォーマンス

Question

私は、次の表の構造を持っている：

EVENT_ID(INT) EVENT_NAME(VARCHAR) EVENT_DATE(DATETIME) EVENT_OWNER(INT) 

を私は、テキストフィールドまたは非常に大きなVARCHARあるべきフィールドEVENT_COMMENTSを追加する必要があります。

私はこのテーブルをクエリする場所が2つあります。そのうちの1つは、すべてのイベント（そのページではevent_commentsフィールドを表示する必要はありません）をリストしたページです。

また、特定のイベントのすべての詳細をロードする別のページでは、event_commentsフィールドを表示する必要があります。

event_idとそのイベントのevent_commentsで余分なテーブルを作成する必要がありますか？または、そのフィールドを現在のテーブルに追加するだけですか？

言い換えれば、私のテーブルにテキストフィールドがある場合、私は質問しますが、私はSELECTそれは私のテーブルへのクエリのパフォーマンスに影響を与えますか？

Answer 1

の主 キーの上にそれらを一緒に参加し、別のテーブルに追加 列を分割をオフに検討すべきです。

• 表スキャンは、このようにキャッシュの危険性を高め、
• 少ないレコードがページに、したがって、キャッシュに収まるより多くの時間がかかる

の選択をミスします：

はこれがあることを意味しますただし、このフィールドにはジョインが必要ですが、時間がかかります。

このフィールドにこのフィールドを追加すると、それを選択しないクエリは遅くなり、クエリを選択するクエリは高速に実行されます。

Answer 2

同じテーブルに置く必要があります。

Answer 3

はい、パフォーマンスに影響します。少なくとも、昨日公開されたthis articleによると。

それによると、パフォーマンス上の問題を抱えたくない場合は、別のテーブルに配置して、必要に応じてそれらをジョインする方がよいでしょう。

これは相対的なセクションである：

テーブル内の列の数を制限してみてください。テーブル のカラム数が多すぎると、クエリのスキャン時間は、 カラム数よりもずっと長くなります。さらに、 が多く、多くの列があり、通常は でない表がある場合は、NULL値フィールドを持つ のディスク領域を無駄にしてしまいます。 これは、可変サイズの フィールド（テキストやBLOBなど）にも当てはまります。ここでは、 テーブルサイズが大幅に大きくなり、必要以上に大きくなる可能性があります。この場合、あなたは が、それはサイズが大きくなり、あなたのテーブルにフィールドを追加したレコード

Answer 4

はい、おそらく同じテーブルの他のクエリに影響しますが、おそらく気にしないので、とにかく実行する必要があります。

エンジンに依存して、ブロブは、インライン（MyISAM）、部分的にページ外（InnoDB）または完全にオフページ（場合によってはInnoDBプラグイン）に格納されます。

これらは、1ページあたりの行数を減らす可能性があり、したがって、いくつかのクエリを満たすIO操作の数が増加します。

しかし、あなたが気にすることはほとんどありませんので、とにかくやるべきです。この表には何行ありますか？ 10^9？それらのどれくらいがblobにnull以外の値を持っていますか？

Answer 5

パフォーマンスが心配される場合は、benchmarksを実行し、クエリにEXPLAINsを実行して、実際の効果を確認する必要があります。

Answer 6

予定しているイベントはいくつですか？

もしあなたが数十万イベントの荷物を持っていなければ、あなたのパフォーマンスはどんな場合でも良いでしょう。