-1

大きなテーブルをメモリ最適化テーブルに置き換えました
いくつかのものについては、いくつかのものに対して良い応答時間が得られますそれは終了します
それは複合主キーです主キー
を使用できるようにする唯一の方法は、特定の行を検索することです（ PK 全体)
並べ替えに PK を使用しない、または複合キーの 1 つのコンポーネントのみを使用する
既存のデータからハッシュ バケットのサイズを決定する

複合主キー
Hekaton のこのリンクの構文を使用しました: create table ステートメントの複合主キー
CREATE TABLE (SQL Server)

CREATE TABLE [dbo].[FTSindex]
(
    [sID] [int] NOT NULL,
    [wordPos] [int] NOT NULL,
    [wordID] [int] NOT NULL,
    [charPos] [int] NOT NULL,

INDEX [ix_wordID_MO_2] NONCLUSTERED HASH 
(
    [wordID]
)WITH ( BUCKET_COUNT = 524288),
CONSTRAINT [pk_FTSindexMO_2] PRIMARY KEY NONCLUSTERED HASH 
(
    [sID],
    [wordPos]
)WITH ( BUCKET_COUNT = 268435456)
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY )

select top 10 * from [FTSindex] where [sID] = 100
-- runs in 0 seconds 
-- Index Seek on ix_wordID_MO_2 
-- it is NOT using the PRIMARY KEY pk_FTSindexMO_2

select top 10 * from [FTSindex] where [wordPos] = 100
-- never finishes (I only waited 10 minutes) 
-- will not even display an execution plan

select top 10 * from [FTSindex] where [sID] = 100 and [wordPos] < 1000
-- never finishes (I only waited 10 minutes) 
-- will not even display an execution plan


select top 10 * from [FTSindex] order by [sID]
-- never finishes (I only waited 10 minutes) 
-- query plan is Table Scan 

select top 10 * from [FTSindex] order by [sID], [wordPos]
-- never finishes (I only waited 10 minutes) 
-- will not even display an execution plan

select top 10 * from [FTSindex] where [wordID] = 100 and [sID] = 856515 
-- runs in 0 seconds
-- Index Seek on ix_wordID_MO_2

select top 10 * from [FTSindex] where [wordID] = 100 and [sID] = 856515  and [wordPos] < 1000
-- never finishes (I only waited 10 minutes) 
-- will not even display an execution plan

select * from [FTSindex] where [sID] = 100  
-- 45 seconds to return 1500 rows 
-- table scan 

select * from [FTSindex] where [sID] = 100  and [wordPos] = 1133 
-- runs in 0 seconds
-- this uses the pk_FTSindexMO_2 
-- this is the only way I could get it to use the primary key

元の（メモリ最適化されていないテーブル）に注意してください
これらのクエリはすべて0秒で実行されますが、 すべてが0秒で実行される
という意味ではありません

これは私の問題を要約していると思います
メモリ最適化ハッシュ インデックスに関する一般的なパフォーマンスの問題のトラブルシューティング

主キーに HASH を使用しないことで修正されたようです 

CREATE TABLE [dbo].[FTSindex]
(
    [sID] [int] NOT NULL,
    [wordPos] [int] NOT NULL,
    [wordID] [int] NOT NULL,
    [charPos] [int] NOT NULL,

INDEX [ix_wordID_MO_2] NONCLUSTERED HASH 
(
    [wordID]
)WITH ( BUCKET_COUNT = 524288),
CONSTRAINT [pk_FTSindexMO_2] PRIMARY KEY NONCLUSTERED 
(
    [sID] ASC,
    [wordPos] ASC
)
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY )

最後に、古いディスク ベースのテーブルに戻り
ます アプリケーションで使用される実際のクエリでは、最適化されたメモリは低速
でした

4

1 に答える 1

2

ハッシュ インデックスは、範囲スキャンには使用できません。範囲インデックスは.

于 2014-05-13T21:43:54.523 に答える