本質的にログ テーブルにクラスター化された PK がありますが、これは明らかにクラスター化すべきではありません。
私がする時：
alter table mytable drop constraint pk_mytable
私のマシン上のDBのコピーには絶対的な経過時間（5分以上）がかかるため、タイムアウトやタイムアウト自体を引き起こさずに、常に本番DBでは機能しません。
なぜこれはインスタント操作ではないのですか? それは何をしているのですか？
サイトをオフラインにせずにこれを達成する方法はありますか?
更新:テーブルには数千万の行があり、数 5? その他の非クラスター化インデックス
ありがとう
主キーを削除しようとしているときに、テーブルに何らかの形式のロックがあると思われます。一般的に言えば、実際には、各テーブルにクラスター化インデックスを作成することをお勧めします。これにより、削除や更新などの一部の操作が実際に高速化されます。テーブルがログテーブルであるという事実以外に、これを削除したい理由は何ですか?. 繰り返しになりますが、一般的に言えば、問題のテーブルが、同時/大規模な挿入を高速にする必要がある何らかの形式のステージングテーブルである場合にのみ、ヒープを使用する傾向があります。したがって、パフォーマンスの問題がありますか?テーブルに挿入するときに定量化できますが、クラスター化された主キーを削除する別の実行可能な理由は、クラスターキーが間違っていることです。つまり、幅が広く、揮発性があり、単調に増加していません。ただし、回転するディスク ベースのストレージと同じようにランダム I/O の影響を受けないソリッド ステート ベースの I/O サブシステムを使用している場合を除きます。Nigels の言うことは正しいです。これに対する例外は SQL Azure です。これには、** すべての ** テーブルにクラスター化されたインデックスが必要であり、HA アーキテクチャはこれに依存しています。