OK、最初に免責事項。いくつかのテーブルでエンティティ属性値アプローチを使用しています。したがって、基本的には、1 つのテーブルの 1 つの列に属性のリストがあり、それを別のビューの 1 つの行に入力したいと考えています。
私はこの解決策を見つけました、そしてそれはうまくいきます:
SQL: ソース テーブルの列値に基づく列名を持つ動的ビュー
ただし、初期ロードは非常に低速でした (514 行を入力するのに 27 分以上かかりました)。何かがおかしいと思ったので、TOP を使用して Client テーブルの一部を選択してみました。すぐに結果が出ました。この方法で、データベース全体を即座にキューに入れることができることがわかりました。しかし、私は非常に奇妙な警告を見つけました。選択できた最大数は 5250 レコードでした。
この時点まで、私はまだ即座に結果を得ていました。5251 を選択しようとすると、クエリがハングします。テストサーバーで試してみたところ、同じ制限がありましたが、数値が異なりました (最大 5321 を選択できました)。テーブルには 514 レコードしかないことに注意してください。そのため、TOP 選択に 1 つの数字を追加するとハングする理由がわかりません。誰かがこれに何か意見を持っていますか? 以下は、私の作業中のSQLクエリです。
DECLARE @cols AS NVARCHAR(MAX)
DECLARE @query AS NVARCHAR(MAX)
select @cols = STUFF((SELECT distinct ',' + QUOTENAME(a.AttributeName)
from AttributeCodes a
FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)')
,1,1,'')
set @query = 'SELECT TOP 5250 ClientID, ' + @cols + ' from
(
select c.ClientID
, c.[Value]
, a.AttributeName
from Client c
inner join AttributeCodes a
on a.AttributeCodeId = c.AttributeCodeID
)x
pivot
(
min([Value])
for AttributeName in (' + @cols + ')
)p'
execute(@query)
編集:
問題は、別の桁を追加することによって実行計画が完全に変更されたことにあるようです。以下に2つの結果を掲載します。なぜそれが変わるのかはまだわかりません.Inner Joinの代わりにHash Matchを使用しないようにする方法があれば.
実行計画 1 (インスタント):
実行計画 2 (30 分以上):