350,000行以上のMySQL-InnoDBテーブルがあり、id、otherId、shortTitleなどがいくつか含まれています。今、私はそれらの行のおそらく数百または数千のブール/ビットフィールドを必要としています。そのboolフィールドをテーブルに追加するだけでよいのでしょうか、それとも古いテーブルのIDを参照する新しいテーブルを作成するのが最善でしょうか。これにより、最初のテーブルにアクセスするすべての古い既存の関数でパフォーマンスの問題が発生するリスクがなくなります。
（補足情報：「SELECT * ...」を使用したことはありません。メインテーブルには多くの読み取りがあり、書き込みはめったにありません。）
テーブルの行が大きくなるため、フィールドを追加するとパフォーマンスが少し低下する可能性がありますが、フィールドではほとんど問題になりませんBIT。
ほとんどの場合、ページあたりの行数はまったく同じです。つまり、パフォーマンスがまったく低下することはありません。
一方、JOIN別のテーブルの行の値にアクセスするためにエクストラを使用すると、はるかに遅くなります。
列をテーブルに追加します。
新しい列は何を示していますか？
データモデリングの観点から、列が使用されている通常の形式のデータに属している場合は、データと一緒に配置します。パフォーマンスへの影響は気にしないでください。列がテーブルに直接属していない場合は、外部キーを使用して2番目のテーブルに配置します。
現実的には、最大350,000のテーブルに新しい列を追加することによるパフォーマンスへの影響は、特に大きくなることはありません。ALTER TABLEおそらくローカルワークステーションで、コピーに対してステートメントを発行しようとしましたか？
なぜ人々が350K列のテーブルを大きく主張するのか分かりません。メインフレームの世界では、それがDBMS構成テーブルの大きさです:-)。
そうは言っても、テーブルは第3正規形で設計する必要があります。パフォーマンスに問題がある場合に限り、非正規化を検討する必要があります。
特定の行にのみ適用される列がある場合、同じテーブルに配置するのは（おそらく）3NFにはなりません。'primary'テーブルに外部キーを含む別のテーブルが必要です。
これは、ブールフィールドが実際に一部の行に適用されない場合であることに注意してください。これは、すべての行に適用されるフィールドとは異なる状況ですが、一部の行には知られていません。その場合、プライマリテーブルのnull許容列の方が適しています。しかし、それはあなたが説明しているもののようには聞こえません。
次のエントリにビットフィールドを要求することは、継承を実装したいように聞こえるだけです。その場合は、読みやすくするために新しいテーブルに追加します。それ以外の場合は、クエリがインデックスを使用していない場合を除いて、メインテーブルに追加するかどうかは関係ありません。インデックスを使用していない場合は、パフォーマンスに関する他の決定を行う前に、まずインデックスを変更します。