SQL Server 2005に249個の非クラスター化インデックスがあるのはなぜですか?なぜ240または300ではないのですか?SQL Server 2008についても同じ質問ですが、なぜ999なのですか?なぜ800または1000ではないのですか?
5 に答える
彼らはかなり(丸められた)数字を作っています...
SQL Server 2005: 1つのクラスター化インデックス+249の非クラスター化インデックス=テーブルあたり250のインデックス
SQL Server 2008: 1つのクラスター化インデックス+999の非クラスター化インデックス=テーブルあたり1000のインデックス
更新:
SQL Server 2008でなぜ999なのかを尋ねるべきでした。これは、私の質問
への回答で説明されていました。この増加は、SQLServer2008でのフィルター処理されたインデックスの導入によって説明されました。
sysindexesのindex_idのデータ型は次のことを意味します。
- ヒープの場合は0
- 1-クラスター化されたインデックス
- >1非クラスター化
- >=3200-XMLインデックス
したがって、SQL Serverの将来のバージョンでは、3198(3199-1)までの増加を引き続き観察できます。
以前、sys.indexesはsysindexesの同義語だと思っていましたが、ちょうど今、それらが異なり、sysindexesには(index_idではなく)indidがあり、XMLインデックスの行が含まれていないことがわかりました。
sys.indexesのindex_idの型はint(4bytes)で、sys.sysindexesのindidの型はsmallint(2bytes)です(SQL Server 2008、おそらく以前のバージョンから増加)
TiborKarasziという記事が役に立ち興味深いと思いました。sys[。]インデックスのキーカウント
ちなみに、これらは恣意的な制限であり、実際に遭遇する人はほとんどいません。おそらく、内部構造に割り当てるスペースの量を知るために、最大制限を設定する必要があります。たぶん彼らdecimal(3,0)
は、indexidを保存するのに十分だと判断しただけです!
彼らがSQLServer2008で許可していたとしたら、なぜそうしないのか1000
と尋ねるでしょう。1001
ええと、SQLServer2005以前の場合。
- 0=ヒープ。インデックスがない場合でも、すべてのテーブルには少なくともsys.indexesのエントリがあります
- 1=クラスター化
- 255 = SQL Server 2000以前のLOB列の場合(理由を今思い出せない)
したがって、すぐに最大253個のNCインデックス(2〜254)が得られました。
丸め?または、いくつかのレガシーSQL Server 7.0 / 6.5 / 6.0 / 4.2の理由はありますか?
SQL Serverの初期のバージョンでは、インデックスIDにtinyintフィールドが使用されていました。Tinyintの最大値は255です。設計チームは、覚えやすいようにこれを250に切り捨てた可能性があります(varcharフィールドの8000文字の制限で行ったように)。250個のインデックスが分割されます。1個のクラスター化インデックスと249個の非クラスター化インデックスです。
これは基本的に内部実装の制限です。これは、メタデータサイズ(つまり、index_idのtinyint列または小さなint列)によって駆動されるのではなく、内部制限を反映するメタデータ列です。
そのような制限が表面化するときはいつでも、それはコードのどこかにこれがどのように扱われるかについての実際的な制限があることを意味します。例を挙げると、同じテーブル上の数万のインデックスを考慮する必要がある場合、クエリプランの生成は複雑になりすぎ、簡単なプランを作成するのにさらに時間がかかる可能性があります。このような問題に直面した場合、「合理的な」数と見なされるものに線が引かれます。90年代後半には約250のインデックスが妥当と思われ、R2では制限が1000にプッシュされました。