データベースにテーブルを作成します。テーブルは最初から生成され、おそらくは再度書き込まれることはありません。これまで書かれていたとしても、リリース中に実行されるバッチプロセスの形になり、書き込み時間はまったく重要ではありません。読み取り専用テーブルのすべての列にインデックスを付ける
これは、約80k行、おそらく約10-12列の比較的大きなテーブルです。
アプリケーションは、このテーブルから頻繁にデータを取得する可能性があります。
私はすべての列にインデックスを付けるだけでもう一度書かれないので、私は考えていましたか？そのようにすれば、私はどんなタイプの質問を作成しても、それはいつも素早く読むことができます。
これは良い考えですか？私が知っておくべきこれの欠点はありますか？
私の理解では、各索引にはいくつかの（比較的少量の）記憶領域が必要です。あなたがスペースのためにきついのであれば、これは重要かもしれません。これがどれくらいの影響を及ぼすかは、使用しているDBによって異なります。
これは表によって異なります。すべての列が検索基準で使用される場合は、すべての列に索引を付けることは不合理ではありません。それはかなり起こりそうもない。また、単純な（単一列の）インデックスよりも有益な複合（複数列）インデックスが存在する可能性があります。
最後に、クエリオプティマイザは、回答クエリの評価時にテーブルに存在するすべてのインデックスを確認する必要があります。これが測定可能なオーバーヘッドになるとは言い難いですが、索引の所要時間が長くなります。
したがって、あなたが記述するテーブルの静的な性質を考慮すると、より動的なテーブルよりも重度に索引付けすることは妥当です。おそらく、すべての列をインデックス化するのは分かりません。追加する複合インデックスを慎重に選択することも重要です。
テーブルに対して実行するクエリに基づいてテーブルのインデックスを選択します。
すべてのクエリで必要としないインデックスは、無駄なスペースです。
各列の個別の索引は、可能な索引の完全なセットではありません。また、複数の列のインデックス（複合インデックス）を作成することもできます。これらのインデックスは、特定のクエリを最適化するために重要です。複合インデックスの列の順序は重要です。
SQL Server 2008では、テーブルごとに999のノンクラスタードインデックスのみがサポートされています。したがって、複数の列のテーブルにすべての可能なインデックスを作成しようとすると、制限に達します。
申し訳ありませんが、効果的に最適化するには実際にいくつかのことを学ぶ必要があります。単に各列の索引付けの問題であれば、RDBMSはデフォルトでこれを行います。
必須ではありません：可能性のある値が2つまたは3つしかない「性別」列のように、選択性が非常に低い列がある場合、インデックスはオーバーヘッドになり、使用されないため完全に役に立たなくなります。また、クエリパターンによっては、多数の小さい（1列）インデックスではなく、いくつかのより広いインデックス（複数の列を含む）を作成する方が良いかもしれません。しかし、それはあなたのクエリ（およびあなたのテーブル構造） –