13

ストック オプションのデータベースをセットアップするために mySQL を使用しています。約 330,000 行あります (各行は 1 つのオプションです)。私は SQL を初めて使用するので、オプション記号 (4 ～ 5 文字)、株式記号 (1 ～ 5 文字)、会社名 (5 ～ 60 文字) などのフィールド タイプを決定しようとしています。文字）。

速度を最適化したい。両方ともデータベースを作成します (新しい価格データが出てくると 5 分ごとに発生します。リアルタイムのデータ フィードはありませんが、330,000 行の新しいテキスト ファイルが配信されるという点でほぼリアルタイムです)。 5 分ごと; この新しいデータは以前のデータを完全に置き換えます)、また検索速度のためにも使用されます (多くのユーザーがアドホック クエリを実行できる Web ベースのフロント エンドがあります)。

スペースについて心配していない場合 (db の有効期間は 5 分で、各行にはおそらく 300 バイトが含まれているため、全体で 100MB になる可能性があるため)、フィールドを構造化する最速の方法は何ですか?

実際、数値フィールドに関する同じ質問: int(11) と int(7) の間にパフォーマンスの違いはありますか? クエリと並べ替えでは、ある長さが別の長さよりもうまく機能しますか?

ありがとう！

4

5 に答える 5

34

MyISAM では、固定幅のレコードを作成する利点があります。VARCHAR は可変幅です。CHAR は固定幅です。行に固定幅のデータ型しかない場合、行全体が固定幅になり、MySQL はそのテーブル内の行のスペース要件とオフセットを計算する利点を得ることができます。とは言っても、利点は小さいかもしれませんし、VARCHAR がよりコンパクトに格納される固定幅のパディングされた CHAR 列を持つことによる他のコスト (キャッシュ効率など) が上回る可能性のあるわずかな利益の価値はほとんどありません。

より効率的になるブレークポイントはアプリケーションによって異なります。これは、両方のソリューションをテストし、アプリケーションの使用状況でデータに最適なソリューションを使用しない限り、答えられるものではありません。

INT(7) 対 INT(11) に関しては、これはストレージやパフォーマンスとは関係ありません。INT 型に対する MySQL の引数がデータのサイズと関係があるというのはよくある誤解ですが、そうではありません。MySQL の INT データ型は常に 32 ビットです。括弧内の引数は、ZEROFILL で値を表示する場合に埋め込む桁数を示します。たとえば、INT(7) は 0001234 を表示し、INT(11) は 00000001234 を表示します。ただし、このパディングは値が表示されるときにのみ発生し、ストレージまたは数学の計算中には発生しません。

于 2008-12-08T18:07:17.637 に答える
6

フィールド内の実際のデータのサイズが大きく異なる可能性がある場合、レコードが小さくなるため varchar の方が優れており、レコードが小さいほど DB が高速になります (より多くのレコードがキャッシュに収まり、インデックスが小さくなるなど)。同じ理由で、最大速度が必要な場合は、小さい int を使用することをお勧めします。

OTOH、分散が小さい場合、たとえばフィールドの最大値が 20 文字で、ほとんどのレコードが実際には 20 文字近くの長さである場合、DB による追加の最適化が可能になるため、char の方が優れています。ただし、これは、テーブル内のすべてのフィールドに当てはまる場合にのみ重要です。これは、固定サイズのレコードがあるためです。速度が主な関心事であり、固定サイズ フィールドのみを使用するクエリがある場合 (または Shotgun クエリのみがある場合) は、固定サイズ以外のフィールドを別のテーブルに移動する価値があるかもしれません。

最終的には、実際のアプリのアクセス パターンに大きく依存するため、一般化することは困難です。

于 2008-12-08T17:21:26.793 に答える
4

システムの制約を考えると、固定幅の文字を使用するために配置したパディングに対応する必要があるため、varchar をお勧めします。これは、どこかでデバッグが必要なコードが増え、エラーの可能性が高くなることを意味します。そうは言っても：

アプリケーションの主なボトルネックは、5 分ごとにデータベースを削除して再作成することです。varchar ではなく char を選択するなどのマイクロ拡張からパフォーマンス上の利点をあまり得られません。代わりに、対処すべきより深刻なアーキテクチャ上の問題がいくつかあると思います。- お姫様

上記のコメントに同意します。char と varchar の違いについて心配する余裕ができる前に、アーキテクチャで揚げるより大きな魚があります。1 つは、アドホック クエリを実行しようとしている Web ユーザーがいて、データベースが再作成中の場合、エラー (つまり、「データベースが存在しません」または単に「タイムアウト」タイプの問題) が発生します。 ）。

代わりに、(少なくとも) 最新のクオート データ (タイム スタンプ付き) のクオート テーブル、ティッカー シンボル テーブル、および履歴テーブルを作成することをお勧めします。Web ユーザーはティッカー テーブルに対してクエリを実行して、最新のデータを取得します。存在しない 5 分間のファイルにシンボルが表示された場合、新しい情報をクオート テーブルにポストする前に、インポート スクリプトでシンボルを作成するのは簡単です。他のすべては更新され、クエリはデフォルトで当日のデータになります。

于 2008-12-08T18:08:25.000 に答える
1

また、データベースの作成は、実際に使用するデータベースの実装に左右されることを忘れないでください。MySQLからたとえばPostgresqlに移植する場合、postgresqlでデータベースを作成するのは比較的非常に遅い操作であるという非常に不快な事実に気付くでしょう。たとえば、テーブルの行の読み取りと書き込みよりも桁違いに遅くなります。

適切なデータ型を選択してパフォーマンスを最適化する前に、最初に対処するアプリケーション設計の問題があるようです。

于 2010-01-04T15:30:00.027 に答える
1

毎回データベースを再作成することは絶対にありません。代わりに、次のことを行います。

  • 更新/スナップショット ファイルを読み取り、各行に基づいてオブジェクトを作成します。
  • 行ごとにシンボル/オプション名（一意）を取得し、データベースに設定します

私だったら、すべてのシンボルと現在の価格データのメモリ内キャッシュも持っているでしょう。

価格データは int ではありません。文字を使用できます。

特定の会社には多くのオプションがあるため、会社名はおそらく一意ではありません。これはインデックスである必要があり、会社の ID を使用するだけでスペースを節約できます。

他の誰かが指摘したように、Web クライアントは実際のデータベースにアクセスしてクエリを実行する必要はありません。おそらくキャッシュにヒットするだけでかまいません。（ただし、クライアントに公開するテーブルとデータ、およびクライアントが必要とするデータによって異なります）

他のユーザーがクエリにアクセスできることも、データベースの削除と作成を続けてはならない理由です。

于 2009-04-07T19:10:25.020 に答える