0

どういうわけか、書き込み時にデータベースが遅すぎます。

現在、2,127,227 行を含む 319MB を使用しています。最初の数日間、コンピューターは 1 秒あたり数千行を挿入できましたが、今では 1,000 行を挿入するのに永遠にかかっています。現在、1,000 行を挿入するのに 165 秒かかります (1 行あたり 0.165)。1 分あたり 10,000 (行あたり 0.006) を挿入できる必要があります。

以下の私のテーブルとサーバーの仕様の設計を見て、これを最適化するのを手伝ってくれるかどうか教えてください. ありがとうございました。

Current usage report
Records 2,127,227
Reserveed KB 323,088
Data(KB) 177,088

設計された私のテーブルはこのようなものです、私はインデックスを作りました[LoginID] ASC,[ProductID] ASC, [ProductModifiedDate] 

CREATE TABLE [dbo].[ProductTable](
    [ID] [uniqueidentifier] NOT NULL,
    [LoginID] [int] NULL,
    [ProductID] [int] NULL,
    [ProductPrice] [decimal](18, 4) NULL,
    [ProductModifiedDate] [datetime] NULL,
    [ProductCreatedDate] [datetime] NULL,
 CONSTRAINT [PK_ProductTable] PRIMARY KEY CLUSTERED 
([ID] ASC)

CREATE NONCLUSTERED INDEX [IX_ProductTable] ON [dbo].[ProductTable] 
(
    [LoginID] ASC,
    [ProductID] ASC,
    [ProductModifiedDate] ASC
)

私の挿入ステートメントは、通常の単純な sql ステートメントであり、特別なことは何もありませんでした。

私のハードウェア:

SQL Server 2008 R2 Express Edition を搭載した 16GB DDR3 RAM を搭載した 2 Quad 2.83 Ghz を使用しています。これらの行を挿入するとき、CPU は 25% の容量で実行されています。

このテーブルを最適化する方法を教えてください。これらすべての列を検索できるようにする必要があるため、これらの列のインデックス作成は非常に重要であり、行を最大 30 日間保持する必要があると思います。

SQL Server Express エディションは 10GB のデータをサポートできると思いました。

4

1 に答える 1

0

新しいレコードを追加するとき、どのように UUID を生成していますか?

完全にランダムな UUID を使用すると、インデックスの断片化が非常に悪くなる可能性があります。これは、データ (行) レイアウト自体が影響を受けるため、クラスター化インデックスの場合は特に厄介です。

NEWID と NEWSEQUENTIALIDを参照してください

最も顕著なのは、NEWID システム関数によって必要とされる書き込みの数です。これは、69% の平均ページ密度と相まって、リーフ レベルでの挿入のランダムな分布によって引き起こされたページ分割の証拠です。ページがいっぱいになるとすぐに、挿入を完了するために、それぞれ 50% の 2 つのページに分割する必要があります。ページ分割によってページ密度が低下しただけでなく、データ ページがかなり断片化されました (次のデータ ページが現在のデータ ページの隣にない可能性は 99% です)。

そして、それは 50k レコードのみです :-) 上記のリンクは、テーブル統計を表示する TSQL スニペットも提供します。

同様に、補助インデックスをチェックします (必要に応じて再構築します)。

于 2012-07-20T04:35:52.060 に答える