インメモリ OLTP での初期領域の調査Survey of Initial Areas in In-Memory OLTP

適用対象: ○SQL Server ○Azure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

この記事は、Microsoft SQL Server と Azure SQL データベースのインメモリ OLTP パフォーマンス機能の基本を短時間で学習する開発者を対象にしています。This article is for the developer who is in a hurry to learn the basics of the In-Memory OLTP performance features of Microsoft SQL Server and Azure SQL Database.

この記事では、インメモリ OLTP の以下のことについて説明します。For In-Memory OLTP, this article provides the following:

  • 機能の概要。Quick explanations of the features.
  • 機能を実装する主なコード サンプル。Core code samples that implement the features.

SQL Server および SQL データベースにおけるインメモリ テクノロジのサポートにはわずかな違いしかありません。SQL Server and SQL Database have only minor variations in their support of In-Memory technologies.

インメモリ OLTP は、一部のブログでは Hekatonと呼ばれています。In the wild some bloggers refer to the In-Memory OLTP as Hekaton.

インメモリ機能の利点Benefits of In-Memory Features

SQL Server では、多くのアプリケーション システムのパフォーマンスを大幅に改善できるインメモリ機能が提供されます。SQL Server provides In-Memory features that can greatly improve the performance of many application systems. この記事では考慮事項を簡単に説明します。The most straight forward considerations are described in this section.

OLTP (オンライン トランザクション処理) の機能Features for OLTP (Online Transactional Processing)

多数の SQL INSERT を同時に処理する必要があるシステムには OLTP 機能が最適です。Systems which must processes large numbers of SQL INSERTs concurrently are excellent candidates for the OLTP features.

  • ベンチマークでは、インメモリ機能を導入することで速度が 5 倍から 20 倍に向上することが示されています。Our benchmarks show that speed improvements from 5 times to 20 times faster are achievable by adoption of the In-Memory features.

Transact-SQL で大量の計算を処理するシステムには最適です。Systems which process heavy calculations in Transact-SQL are excellent candidates.

  • 大量計算専用のストアド プロシージャでは、実行速度が最大 99 倍になります。A stored procedure that is dedicated to heavy calculations can run up to 99 times faster.

後で、インメモリ OLTP によるパフォーマンスの向上を実証する以下の記事を参照してください。Later you might visit the following articles which offer demonstrations of performance gains from In-Memory OLTP:

運用分析の機能Features for Operational Analytics

インメモリ分析では、通常、GROUP BY 句を含めることによってトランザクション データを集計する SQL SELECT を参照します。In-Memory Analytics refers to SQL SELECTs which aggregate transactional data, typically by inclusion of a GROUP BY clause. 運用分析では主に 列ストア というインデックスの種類が使用されます。The index type called columnstore is central to operational analytics.

2 つの主なシナリオを以下に示します。There are two major scenarios:

  • バッチ運用分析 では、営業時間後に実行されるか、トランザクション データのコピーを持つセカンダリ ハードウェアに対して実行される集計処理を参照します。Batch Operational Analytics refers to aggregation processes that run either after business hours or on secondary hardware which has copies of the transactional data.
  • リアルタイム運用分析 では、営業時間内およびトランザクション ワークロードに使用されるプライマリ ハードウェアで実行される集計処理を参照します。Real-time Operational Analytics refers to aggregration processes that run during business hours and on the primary hardware which is used for transactional workloads.

この記事では分析ではなく OLTP に焦点を当てています。The present article focuses on OLTP, and not on Analytics. 列ストア インデックスを使用した SQL での分析の詳細については、次の項目を参照してください。For information on how columnstore indexes bring Analytics to SQL, see:


Azure SQL Database - In-Memory Technologies」 (Azure SQL Database - インメモリ テクノロジ) では、インメモリ機能に関する 2 分間のビデオをご覧いただけます。A two minute video about the In-Memory features is available at Azure SQL Database - In-Memory Technologies. ビデオの制作日は 2015 年 12 月です。The video is dated December 2015.


お勧めのブログの投稿を参照しながら、さまざまな観点から列ストア インデックスについて説明します。A sequence of excellent blog posts elegantly explains columnstore indexes from several perspectives. 多くの投稿では、列ストアがサポートしているリアルタイム運用分析の概念について詳しく説明します。The majority of the posts describe further the concept of real-time operational analytics, which columnstore supports. これらの投稿は、2016 年 3 月に Microsoft のプログラム マネージャーである Sunil Agarwal が書いたものです。These posts were authored by Sunil Agarwal, a Program Manager at Microsoft, in March 2016.

リアルタイム運用分析Real-time Operational Analytics

  1. インメモリ テクノロジを使用したリアルタイム運用分析Real-Time Operational Analytics Using In-Memory Technology
  2. リアルタイム運用分析 - 非クラスター化列ストア インデックス (NCCI) の概要Real-Time Operational Analytics - Overview nonclustered columnstore index (NCCI)
  3. リアルタイム運用分析: SQL Server 2016 で非クラスター化列ストア インデックス (NCCI) を使用する単純な例Real-Time Operational Analytics: Simple example using nonclustered clustered columnstore index (NCCI) in SQL Server 2016
  4. リアルタイム運用分析: SQL Server 2016 の DML 運用と非クラスター化列ストア インデックス (NCCI)Real-Time Operational Analytics: DML operations and nonclustered columnstore index (NCCI) in SQL Server 2016
  5. リアルタイム運用分析: フィルターした非クラスター化列ストア インデックス (NCCI)Real-Time Operational Analytics: Filtered nonclustered columnstore index (NCCI)
  6. リアルタイム運用分析: 非クラスター化列ストア インデックス (NCCI) の圧縮遅延オプションReal-Time Operational Analytics: Compression Delay Option for Nonclustered Columnstore Index (NCCI)
  7. リアルタイム運用分析: NCCI とパフォーマンスを使用した圧縮遅延オプションReal-Time Operational Analytics: Compression Delay option with NCCI and the performance
  8. リアルタイム運用分析: メモリ最適化テーブルと列ストア インデックスReal-Time Operational Analytics: Memory-Optimized Tables and Columnstore Index

列ストア インデックスを最適化するDefragment a columnstore index

  1. REORGANIZE コマンドを使用した列ストア インデックスの最適化Columnstore Index Defragmentation using REORGANIZE Command
  2. REORGANIZE の列ストア インデックス マージ ポリシーColumnstore Index Merge Policy for REORGANIZE

データの一括インポートBulk importation of data

  1. クラスター化列ストア: 一括読み込みClustered Column Store: Bulk Load
  2. クラスター化列ストア: データ読み込みの最適化 - 最小ログ記録Clustered Columnstore Index: Data Load Optimizations - Minimal Logging
  3. クラスター化列ストア インデックス: データ読み込みの最適化 - 並行一括インポートClustered columnstore Index: Data Load Optimization - Parallel Bulk Import

インメモリ OLTP の機能Features of In-Memory OLTP

インメモリ OLTP での主な機能を見てみましょう。Let's look at the main features of In-Memory OLTP.

メモリ最適化テーブルMemory-optimized tables

CREATE TABLE ステートメントの T-SQL キーワード MEMORY_OPTIMIZED は、ディスクではなく、アクティブ メモリに存在するテーブルの作成方法を示します。The T-SQL keyword MEMORY_OPTIMIZED, on the CREATE TABLE statement, is how a table is created to exist in active memory, instead of on disk.

メモリ最適化テーブル はアクティブ メモリ内に存在し、ディスク上にセカンダリ コピーを保持します。A Memory-optimized tables has one representation of itself in active memory, and secondary copy on the disk.

  • ディスク上のコピーは、サーバーまたはデータベースがシャットダウンして再起動した後の日常的な復旧に使用されます。The disk copy is for routine recovery after a shutdown-then-restart of the server or database. このメモリとディスクの二重性はユーザーとユーザー コードに対して完全に非表示になります。This memory-plus-disk duality is completely hidden from you and your code.

ネイティブ コンパイル モジュールNatively compiled modules

CREATE PROCEDURE ステートメントの T-SQL キーワード NATIVE_COMPILATION は、ネイティブでコンパイルしするストアド プロシージャの作成方法を示します。The T-SQL keyword NATIVE_COMPILATION, on the CREATE PROCEDURE statement, is how a natively compiled stored procedure is created. T-SQL ステートメントは、データベースがオンラインで循環されるたびにネイティブ プロシージャの初回使用時にコンピューター語コードにコンパイルされます。The T-SQL statements are compiled to machine code on first use of the native proc each time the database is cycled online. T-SQL 命令がそれぞれ解釈されるまで長時間待つ必要はなくなりました。The T-SQL instructions no longer endure slow interpretation of every instruction.

  • ネイティブ コンパイル ストアド プロシージャの結果は、解釈されたストアド プロシージャの 1/100 の時間で得られます。We have seen native compilation result in durations that are 1/100th of the interpreted duration.

ネイティブ モジュールが参照できるのはメモリ最適化テーブルのみで、ディスク ベース テーブルを参照することはできません。A native module can reference memory-optimized tables only, and it cannot reference disk-based tables.

ネイティブ コンパイル モジュールには次の 3 種類があります。There are three types of natively compiled modules:

Azure SQL Database での提供状況Availability in Azure SQL Database

インメモリ OLTP および列ストアは、Azure SQL Database で使用できます。In-Memory OLTP and Columnstore are available in Azure SQL Database. 詳細については、「Optimize Performance using In-Memory Technologies in SQL Database」 (SQL データベースでのインメモリ テクノロジを使用したパフォーマンスの最適化) を参照してください。For details see Optimize Performance using In-Memory Technologies in SQL Database.

1.互換性レベルを 130 以上に設定する1. Ensure compatibility level >= 130

このセクションと以降のセクションでは、インメモリ OLTP 機能の実装に使用できる Transact-SQL 構文をまとめて示します。This section begins a sequence of numbered sections that together demonstrate the Transact-SQL syntax you can use to implement In-Memory OLTP features.

まず、データベースの互換性レベルを少なくとも 130 に設定することが重要です。First, it is important that your database be set to a compatibility level of at least 130. ここでは、現在のデータベースに設定されている現在の互換性レベルを表示する T-SQL コードを示します。Next is the T-SQL code to view the current compatibility level that your current database is set to.

SELECT d.compatibility_level  
    FROM sys.databases as d  
    WHERE d.name = Db_Name();  

次は、必要に応じて互換性レベルを更新するための T-SQL コードを示します。Next is the T-SQL code to update the level, if necessary.


2.スナップショットに昇格させる2. Elevate to SNAPSHOT

トランザクションがディスク ベース テーブルとメモリ最適化テーブルの両方に関与することを、複数のコンテナーにまたがるトランザクションといいます。When a transaction involves both a disk-based table and a memory-optimized table, we call that a cross-container transaction. このようなトランザクションの場合、トランザクションのメモリ最適化部分が、SNAPSHOT と呼ばれるトランザクション分離レベルで動作する必要があります。In such a transaction it is essential that the memory-optimized portion of the transaction operate at the transaction isolation level named SNAPSHOT.

複数のコンテナーにまたがるトランザクションでメモリ最適化テーブルを確実にこのレベルで動作させるには、次の T-SQL を実行してデータベース設定を変更します。To reliably enforce this level for memory-optimized tables in a cross-container transaction, alter your database setting by executing the following T-SQL.


3.最適化ファイル グループを作成する3. Create an optimized FILEGROUP

Microsoft SQL Server では、メモリ最適化テーブルを作成する前に、CONTAINS MEMORY_OPTIMIZED_DATA を宣言するファイルグループを作成する必要があります。On Microsoft SQL Server, before you can create a memory-optimized table you must first create a FILEGROUP that you declare CONTAINS MEMORY_OPTIMIZED_DATA. 作成したファイルグループはデータベースに割り当てられます。The FILEGROUP is assigned to your database. 詳細については、次の項目を参照してください。For details see:

Azure SQL Database では、このようなファイルグループを作成する必要はありません (作成できません)。On Azure SQL Database, you need not and cannot create such a FILEGROUP.

次のサンプルの T-SQL スクリプトでは、インメモリ OLTP のデータベースを有効にし、すべての推奨設定を構成します。The following sample T-SQL script enables a database for In-Memory OLTP and configures all recommended settings. SQL Server と Azure SQL Database の両方で機能します: enable-in-memory-oltp.sqlIt works with both SQL Server and Azure SQL Database: enable-in-memory-oltp.sql.

MEMORY_OPTIMIZED_DATA ファイル グループのデータベースでは、サポートされていない SQL Server 機能もあります。Note that not all SQL Server features are supported for databases with a MEMORY_OPTIMIZED_DATA filegroup. 制限の詳細については、「インメモリ OLTP に対してサポートされていない SQL Server の機能」を参照してください。For details on limitations see: Unsupported SQL Server Features for In-Memory OLTP

4.メモリ最適化テーブルを作成する4. Create a memory-optimized table

重要な Transact-SQL キーワードは MEMORY_OPTIMIZED です。The crucial Transact-SQL keyword is the keyword MEMORY_OPTIMIZED.

CREATE TABLE dbo.SalesOrder  
    SalesOrderId   integer        not null  IDENTITY  
    CustomerId     integer        not null,  
    OrderDate      datetime       not null  

メモリ最適化テーブルに対する Transact SQL の INSERT ステートメントと SELECT ステートメントは、通常のテーブルの場合と同じです。Transact-SQL INSERT and SELECT statements against a memory-optimized table are the same as for a regular table.

メモリ最適化テーブルの ALTER TABLEALTER TABLE for Memory-Optimized tables

ALTER TABLE...ADD/DROP では、メモリ最適化テーブルの列またはインデックスを追加または削除できます。ALTER TABLE...ADD/DROP can add or remove a column from a memory-optimized table, or an index.

  • メモリ最適化テーブルに対して CREATE INDEX や DROP INDEX を実行することはできません。代わりに、ALTER TABLE ...ADD/DROP INDEX を使用してください。CREATE INDEX and DROP INDEX cannot be run against a memory-optimized table, use ALTER TABLE ... ADD/DROP INDEX instead.
  • 詳細については、「 メモリ最適化テーブルの変更」を参照してください。For details see Altering Memory-Optimized Tables.

メモリ最適化テーブルとインデックスの計画Plan your memory-optimized tables and indexes

5.ネイティブ コンパイル ストアド プロシージャ (ネイティブ プロシージャ) を作成する5. Create a natively compiled stored procedure (native proc)

重要なキーワードは NATIVE_COMPILATION です。The crucial keyword is NATIVE_COMPILATION.

CREATE PROCEDURE ncspRetrieveLatestSalesOrderIdForCustomerId  
    @_CustomerId   INT  
        LANGUAGE = N'us_english')  

    DECLARE @SalesOrderId int, @OrderDate datetime;  

    SELECT TOP 1  
            @SalesOrderId = s.SalesOrderId,  
            @OrderDate    = s.OrderDate  
        FROM dbo.SalesOrder AS s  
        WHERE s.CustomerId = @_CustomerId  
        ORDER BY s.OrderDate DESC;  

    RETURN @SalesOrderId;  

SCHEMABINDING キーワードは、ネイティブ プロシージャで参照されているテーブルを削除するには、先にネイティブ プロシージャを削除しておく必要があることを意味します。The keyword SCHEMABINDING means the tables referenced in the native proc cannot be dropped unless the native proc is dropped first. 詳細については、「ネイティブ コンパイル ストアド プロシージャの作成」を参照してください。For details see Creating Natively Compiled Stored Procedures.

メモリ最適化テーブルにアクセスするために、ネイティブでコンパイルされたストアド プロシージャを作成する必要はありません。Note that you do not need to create a natively compiled stored procedure to access a memory-optimized table. 従来のストアド プロシージャとアドホック バッチからメモリ最適化テーブルを参照することもできます。You can also reference memory-optimized tables from traditional stored procedures and ad hoc batches.

6.ネイティブ プロシージャを実行する6. Execute the native proc

テーブルにデータを 2 行挿入します。Populate the table with two rows of data.

INSERT into dbo.SalesOrder  
        ( CustomerId, OrderDate )  
        ( 42, '2013-01-13 03:35:59' ),  
        ( 42, '2015-01-15 15:35:59' );  

EXECUTE によるネイティブ コンパイル ストアド プロシージャの呼び出しが後に続きます。An EXECUTE call to the natively compiled stored procedure follows.

DECLARE @LatestSalesOrderId int, @mesg nvarchar(128);  

EXECUTE @LatestSalesOrderId =  
    ncspRetrieveLatestSalesOrderIdForCustomerId 42;  

SET @mesg = CONCAT(@LatestSalesOrderId,  
    ' = Latest SalesOrderId, for CustomerId = ', 42);  
PRINT @mesg;  

-- Here is the actual PRINT output:  
-- 2 = Latest SalesOrderId, for CustomerId = 42  

ドキュメント ガイドと次のステップGuide to the documentation and next steps

上記の簡単な例では、インメモリ OLTP の高度な機能を学習するための基礎を示しました。The preceding plain examples give you a foundation for learning the more advanced features of In-Memory OLTP. 以降のセクションでは、特に考慮する必要がある事項と、その詳細について説明した参照先を示します。The following sections are a guide to the special considerations you might need to know, and to where you can see the details about each.

インメモリ OLTP 機能が高速で動作するしくみHow In-Memory OLTP features work so much faster

以降のサブセクションでは、インメモリ OLTP 機能が内部でどのように動作してパフォーマンスを向上させているかについて、簡単に説明します。The following subsections briefly describe how the In-Memory OLTP features work internally to provide improved performance.

メモリ最適化テーブルが高速で動作するしくみHow memory-optimized tables perform faster

デュアル構成: メモリ最適化テーブルはデュアル構成になっており、アクティブ メモリ内とハード ディスク上に 1 つずつ存在します。Dual nature: A memory-optimized table has a dual nature: one representation in active memory, and the other on the hard disk. 各トランザクションは両方のテーブルに対してコミットされます。Each transaction is committed to both representations of the table. トランザクションは、より高速なアクティブ メモリ内のテーブルに対して操作を行います。Transactions operate against the much faster active memory representation. そのためメモリ最適化テーブルは、ディスクよりも高速なアクティブ メモリの恩恵を受けることになります。Memory-optimized tables benefit from the greater speed of active memory versus the disk. さらに、アクティブ メモリは非常に敏捷なので、速度に関して最適化されたより高度なテーブル構造も使用できます。Further, the greater nimbleness of active memory makes practical a more advanced table structure that is optimized for speed. 高度なテーブル構造はページレスでもあるため、ラッチやスピンロックのオーバーヘッドや競合を回避できます。The advanced structure is also pageless, so it avoids the overhead and contention of latches and spinlocks.

ロックなし: メモリ最適化テーブルはオプティミスティックなアプローチにより、データの整合性と、コンカレンシーおよび高スループットとのバランスを取っています。No locks: The memory-optimized table relies on an optimistic approach to the competing goals of data integrity versus concurrency and high throughput. トランザクションの間、更新されたデータ行のどのバージョンもロックすることはありません。During the transaction, the table does not place locks on any version of the updated rows of data. これにより、特に大規模システムでは大幅に競合を減らすことができます。This can greatly reduce contention in some high volume systems.

行のバージョン: メモリ最適化テーブルは、更新された行をロックする代わりに、更新された行の新しいバージョンを (tempdb ではなく) テーブルに追加します。Row versions: Instead of locks, the memory-optimized table adds a new version of an updated row in the table itself, not in tempdb. 元の行は、トランザクションがコミットされるまで保持されます。The original row is kept until after the transaction is committed. トランザクションの間も、他のプロセスが行の元のバージョンを読み取ることができます。During the transaction, other processes can read the original version of the row.

  • ディスク ベース テーブルの行に複数のバージョンが作成されると、行のバージョンは一時的に tempdb に格納されます。When multiple versions of a row are created for a disk-based table, row versions are stored temporarily in tempdb.

ログ記録の削減: 行の更新前と更新後のバージョンは、メモリ最適化テーブルに保持されます。Less logging: The before and after versions of the updated rows are held in the memory-optimized table. この行のペアによって、従来はログ ファイルに書き込まれていた情報の多くが提供されるので、The pair of rows provides much of the information that is traditionally written to the log file. システムが書き込むログの量も頻度も少なくて済むようになります。This enables the system to write less information, and less often, to the log. ログの量と頻度が減っても、トランザクションの整合性は保証されます。Yet transactional integrity is ensured.

ネイティブ プロシージャが高速で動作するしくみHow native procs perform faster

通常の解釈されたストアド プロシージャをネイティブ コンパイル ストアド プロシージャに変換すると、実行時の命令の数が大幅に減少します。Converting a regular interpreted stored procedure into a natively compiled stored procedure greatly reduces the number of instructions to execute during run time.

インメモリ機能のトレードオフTrade-offs of In-Memory features

コンピューター サイエンスの世界では一般的なことですが、インメモリ機能によるパフォーマンスの向上にはトレードオフがあります。As is common in computer science, the performance gains provided by the In-Memory features are a trade-off. 優れた機能にはよりコストがかかりますが、それに見合うだけの有益な利点がもたらされます。The better features bring benefits that are more valuable than the extra costs of the feature. トレードオフに関する包括的なガイドは次の場所にあります。You can find comprehensive guidance about the trade-offs at:

このセクションの残りの部分では、主要な計画とトレードオフの考慮事項の一部を示します。The rest of this section lists some of the major planning and trade-off considerations.

メモリ最適化テーブルのトレードオフTrade-offs of memory-optimized tables

メモリの推定: メモリ最適化テーブルが消費するアクティブ メモリの量を見積もる必要があります。Estimate memory: You must estimate the amount of active memory that your memory-optimized table will consume. コンピューター システムに、メモリ最適化テーブルをホストするのに十分なメモリ容量が必要です。Your computer system must have adequate memory capacity to host a memory-optimized table. 詳細については、次の項目を参照してください。For details see:

大規模テーブルのパーティション分割: 大量のアクティブ メモリの需要を満たす方法の 1 つは、大規模なテーブルをパーティション分割して、 使用中の最近の データ行を格納する部分 (メモリ内) と、出荷済みや完了済みの注文など、 使用していない古い 行を格納する部分 (ディスク上) に分けることです。Partition your large table: One way to meet the demand for lots of active memory is to partition your large table into parts in-memory that store hot recent data rows versus other parts on the disk that store cold legacy rows (such as sales orders that have been fully shipped and completed). このパーティション分割は、手動で設計して実装します。This partitioning is a manual process of design and implementation. 次のチュートリアルを参照してください。See:

ネイティブ プロシージャのトレードオフTrade-offs of native procs

  • ネイティブ コンパイル ストアド プロシージャは、ディスク ベース テーブルにアクセスできません。A natively compiled stored procedure cannot access a disk-based table. ネイティブ プロシージャは、メモリ最適化テーブルにのみアクセスできます。A native proc can access only memory-optimized tables.
  • サーバーまたはデータベースがオンラインに戻った後、初めてネイティブ プロシージャを実行するときは、そのネイティブ プロシージャを一度再コンパイルする必要があります。When a native proc runs for its first time after the server or database was most recently brought back online, the native proc must be recompiled one time. そのため、ネイティブ プロシージャが実行するまでに遅延が発生します。This causes a delay before the native proc starts to run.

メモリ最適化テーブルに関する高度な考慮事項Advanced considerations for memory-optimized tables

メモリ最適化テーブルのインデックス は、従来のディスク上のテーブルのインデックスとはいくつかの点が異なります。Indexes for Memory-Optimized Tables are different in some ways from indexes on traditional on-disk tables. ハッシュ インデックスは、メモリ最適化テーブルでのみ使用できます。Hash Indexes are available only on memory-optimized tables.

計画したメモリ最適化テーブルとインデックスのための十分なアクティブ メモリがあることを確認する必要があります。You must plan to ensure there will be sufficient active memory for your planned memory-optimized table and its indexes. 次のチュートリアルを参照してください。See:

メモリ最適化テーブルは DURABILITY = SCHEMA_ONLY で宣言できます。A memory-optimized table can be declared with DURABILITY = SCHEMA_ONLY:

  • この構文は、データベースがオフラインになったときにメモリ最適化テーブルからすべてのデータを破棄するようシステムに指示します。This syntax tells the system to discard all data from the memory-optimized table when the database is taken offline. テーブル定義のみが保持されます。Only the table definition is persisted.
  • データベースがオンラインに復帰すると、メモリ最適化テーブルがアクティブ メモリに読み込まれ、データは空になります。When the database is brought back online, the memory-optimized table is loaded back into active memory, empty of data.
  • 数千の行が含まれている場合は、tempdb の #temporary テーブルよりも SCHEMA_ONLY テーブルの方が適していることがあります。SCHEMA_ONLY tables can be a superior alternative to #temporary tables in tempdb, when many thousands of rows are involved.

テーブル変数をメモリ最適化として宣言することもできます。Table variables can also be declared as memory-optimized. 次のチュートリアルを参照してください。See:

ネイティブ コンパイル モジュールに関する高度な考慮事項Advanced considerations for natively compiled modules

Transact-SQL で使用可能なネイティブ コンパイル モジュールの種類:The types of natively compiled modules available through Transact-SQL are:

ネイティブ コンパイルのユーザー定義関数 (UDF) は、解釈された UDF よりも高速で実行されます。A natively compiled user defined function (UDF) runs faster than an interpreted UDF. UDF に関するいくつかの考慮事項を以下に示します。Here are some things to consider with UDFs:

  • T-SQL SELECT で UDF を使用する場合は、返される行ごとに常に 1 回 UDF が呼び出されます。When a T-SQL SELECT uses a UDF, the UDF is always called once per returned row.
    • UDF はインラインで実行されることはなく、常に呼び出されます。UDFs never run inline, and instead are always called.
    • コンパイル済みであるかどうかは、すべての UDF で繰り返される呼び出しのオーバーヘッドに比べると、あまり重要ではありません。The compiled distinction is less significant than is the overhead of repeated calls that is inherent to all UDFs.
    • それでも、UDF 呼び出しのオーバーヘッドは、多くの場合、実用レベルでは許容可能です。Still, the overhead of UDF calls is often acceptable at the practical level.

ネイティブ UDF のパフォーマンスに関するテスト データと説明については、以下を参照してください。For test data and explanation about the performance of native UDFs, see:

メモリ最適化テーブルのドキュメント ガイドDocumentation guide for memory-optimized tables

メモリ最適化テーブルの特別な考慮事項について説明した以下の記事も参照してください。Refer to these other articles that discuss special considerations for memory-optimized tables:

ネイティブ プロシージャのドキュメント ガイドDocumentation guide for native procs

目次にある次の記事とその子記事は、ネイティブにコンパイルされたストアド プロシージャについて詳しく説明しています。The following article, and its children articles in the table of contents (TOC), explain the details about natively compiled stored procedures.

インメモリ OLTP を使用して実現できるパフォーマンスの向上を実証するためのコードを提供する記事は以下のとおりです。Here are articles that offer code to demonstrate the performance gains you can achieve by using In-Memory OLTP: