MySQLテーブル関連、解決方法

MySQL テーブルの分割
は次のようになります。私のテーブルの 1 つは 230 個のフィールド (内容はそれほど多くなく、20,000 レコード未満) であり、最近テーブル テーブル分割についての私の理解は、元々 1 つのテーブルにあった多くのフィールドを 2 つ以上のテーブルに分割することです。
しかし、テーブル分割はフィールドを分割するのではなく、テーブルの内容を分割するという情報をインターネットでたくさん見ました。

私の理解が間違っていたら教えていただけますか?


-----解決策---------ソファの衝突

------解決策--------実際には、2 つの方法の間に競合はありません。 . 実際の状況によります。

今日のデータ、過去のデータなど、表の内容が分類できる場合は、内容に応じて表が分割されます。

明確な 1 対 1 または 1 対多の構造であれば、リレーショナル データを使用して実装できます。

私の謙虚な意見ですので、気を悪くしないでください。

------解決策---------

話し合う

以上です。230 個のフィールドを含むテーブルがあります (内容はそれほど多くなく、レコード数は 20,000 未満です)。最近、テーブルを 2 つに分割することを検討しました。テーブルとは、もともと 1 つのテーブルにあった多くのフィールドを 2 つ以上のテーブルに分割するものです。
しかし、テーブル分割はフィールドを分割するのではなく、テーブルの内容を分割するという情報をインターネットでたくさん見ました。

私の理解が間違っていたら教えていただけますか?

------解決策------
テーブルは通常、内容と日付に従って分割されています。 ID セグメント。 。テーブルを分割するには、ビジネス側の SQL ステートメントをそれに応じて変更する必要があります。 テーブルには 230 個のフィールドがあります。 。設計に重大な問題があるのでしょうか？

------解決策------
1. サブテーブルには水平方向のサブフィールドがあります。 (サブフィールド) )、垂直方向の分割 (レコード) もあります。必要であれば問題ありません。
2.230 フィールド、20,000 レコードを超える数は大きすぎず、次のことが最適です。慎重にテストおよび分析して、問題の原因となっている特定の場所 (個々の SQL が原因であるかどうかなど) を特定し、具体的な理由を見つけて、データベース構造をさらに方向的に変更します。理由がまだ明らかでない場合は、変更する必要があります。

3. あなたのようなデータ
私たちがよく使用する構造は次のとおりです:
id modelIdattributeId value
1 111 2233 3028

where (111->) ;BMW 5 Series 520Li, 2233->wheelbase)

この方法 レコード数は多いですが、構造がシンプルで、属性の追加と削除が簡単です (構成データがたくさんあります)。各メーカーが提供するデータが異なり、230 以降では不十分な場合があります。)

当社では、この方法をデータとして使用しています。