메모리 액세스에 최적화된 테이블의 테이블 및 행 크기Table and Row Size in Memory-Optimized Tables

이 항목 적용 대상: 예SQL Server예Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServeryesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

SQL Server 2016SQL Server 2016 이전에는 메모리 최적화 테이블의 행 내부 데이터 크기가 8,060바이트를 초과할 수 없었습니다.Prior to SQL Server 2016SQL Server 2016 the in-row data size of a memory-optimized table couldn't be longer than 8,060 bytes. 그러나 SQL Server 2016SQL Server 2016부터 및 Azure SQL Database에서는 이제 여러 큰 열(예: 여러 varbinary(8000) 열) 및 LOB 열(즉, varbinary(max), varchar(max) 및 nvarchar(max))이 있는 메모리 최적화 테이블을 만들고 네이티브 컴파일된 T-SQL 모듈 및 테이블 형식을 사용하여 테이블에 대한 작업을 수행할 수 있습니다.However, starting SQL Server 2016SQL Server 2016 and in Azure SQL Database it is now possible to create a memory-optimized table with multiple large columns (e.g., multiple varbinary(8000) columns) and LOB columns (i.e., varbinary(max), varchar(max), and nvarchar(max)) and perform operations on them using natively compiled T-SQL modules and table types.

8060바이트 행 크기 제한에 맞지 않는 열은 행 외부의 별도 내부 테이블에 배치됩니다.Columns that do not fit in the 8060 byte row size limit are placed off-row, in a separate internal table. 각 행 외부 열에는 해당 내부 테이블이 있으며 단일 비클러스터형 인덱스가 있습니다.Each off-row column has a corresponding internal table, which in turn has a single nonclustered index. 행 외부 열에 사용되는 이러한 내부 테이블에 대한 자세한 내용은 sys.memory_optimized_tables_internal_attributes(Transact-SQL)를 참조하세요.For details about these internal tables used for off-row columns see sys.memory_optimized_tables_internal_attributes (Transact-SQL).

행 및 테이블의 크기를 계산하는 것이 유용한 특정 시나리오도 있습니다.There are certain scenarios where it is useful to compute the size of the row and the table:

  • 테이블에서 사용하는 메모리의 양How much memory does a table use?

    • 테이블에서 사용되는 메모리의 양은 정확하게 계산할 수 없습니다.The amount of memory used by the table cannot be calculated exactly. 여러 가지 요소들이 사용되는 메모리 양에 영향을 줍니다.Many factors affect the amount of memory used. 이러한 요소에는 페이지 기반 메모리 할당, 지역성, 캐시 및 패딩 등이 포함됩니다.Factors such as page-based memory allocation, locality, caching, and padding. 또한 연관된 활성 트랜잭션을 포함하는 행이나 가비지 수집을 대기 중인 행 등 여러 가지 버전의 행이 존재할 수 있습니다.Also, multiple versions of rows that either have active transactions associated or that are waiting for garbage collection.

    • 테이블의 데이터 및 인덱스에 필요한 최소 크기는 아래에서 설명하는 [table size]에 대한 계산으로 제공됩니다.The minimum size required for the data and indexes in the table is given by the calculation for [table size], discussed below.

    • 메모리 사용량에 대한 계산은 아무리 잘해도 근사값만 얻을 수 있으며, 배포 계획에 용량 계획을 포함하는 것이 좋습니다.Calculating memory use is at best an approximation and you are advised to include capacity planning in your deployment plans.

  • 행의 데이터 크기 및 8,060바이트 행 크기 제한에 맞는지 여부.The data size of a row, and does it fit in the 8,060 byte row size limitation? 이 질문에 답변하려면 아래 설명된 [row body size] 계산을 사용합니다.To answer these questions, use the computation for [row body size], discussed below.

    메모리 최적화 테이블은 행의 컬렉션과 행에 대한 포인터를 포함하는 인덱스로 구성됩니다.A memory-optimized table consists of a collection of rows and indexes that contain pointers to rows. 다음 그림에서는 인덱스 및 행을 포함하며 차례로 행 헤더와 본문을 가지는 테이블을 보여줍니다.The following figure illustrates a table with indexes and rows, which in turn have row headers and bodies:

    메모리 액세스에 최적화된 테이블입니다.Memory optimized table.
    인덱스와 행으로 구성된 메모리 액세스에 최적화된 테이블Memory-optimized table, consisting of indexes and rows.

테이블 크기 계산Computing Table Size

테이블의 메모리 내 크기(바이트)는 다음과 같이 계산됩니다.The in-memory size of a table, in bytes, is computed as follows:

[table size] = [size of index 1] + … + [size of index n] + ([row size] * [row count])  

해시 인덱스의 크기는 테이블을 만들 때 고정되며 실제 버킷 수에 따라 달라집니다.The size of a hash index is fixed at table creation time and depends on the actual bucket count. 인덱스 사양으로 지정된 bucket_count는 [실제 버킷 수]를 얻기 위해 가장 가까운 2의 제곱으로 반올림됩니다.The bucket_count specified with the index specification is rounded up to the nearest power of 2 to obtain the [actual bucket count]. 예를 들어, 지정된 bucket_count가 100000인 경우 인덱스의 [실제 버킷 수]는 131072입니다.For example, if the specified bucket_count is 100000, the [actual bucket count] for the index is 131072.

[hash index size] = 8 * [actual bucket count]  

비클러스터형 인덱스의 크기는 [row count] * [index key size]순입니다.The size of a nonclustered index is in the order of [row count] * [index key size].

행 크기는 헤더 및 본문을 추가하여 계산됩니다.The row size is computed by adding the header and the body:

[row size] = [row header size] + [actual row body size]  
[row header size] = 24 + 8 * [number of indices]  

행 본문 크기 계산Computing Row Body Size

행 구조Row Structure

메모리 최적화 테이블의 행에는 다음과 같은 구성 요소가 있습니다.The rows in a memory-optimized table have the following components:

  • 행 머리글에는 행 버전 관리를 구현하는 데 필요한 타임스탬프가 포함됩니다.The row header contains the timestamp necessary to implement row versioning. 행 머리글에는 위에서 설명한 해시 버킷의 행 체인을 구현하는 인덱스 포인터도 포함됩니다.The row header also contains the index pointer to implement the row chaining in the hash buckets (described above).

  • 행 본문에는 실제 열 데이터가 포함됩니다. 여기에는 Null 허용 열에 대한 Null 배열과 가변 길이 데이터 형식에 대한 오프셋 배열 같은 일부 보조 정보가 포함됩니다.The row body contains the actual column data, which includes some auxiliary information like the null array for nullable columns and the offset array for variable-length data types.

    다음 그림에서는 두 개의 인덱스가 있는 테이블에 대한 행 구조를 보여 줍니다.The following figure illustrates the row structure for a table that has two indexes:

    두 개의 인덱스가 있는 테이블의 행 구조Row structure for a table that has two indexes.

    시작 및 종료 타임스탬프는 특정 행 버전의 유효 기간을 나타냅니다.The begin and end timestamps indicate the period in which a particular row version is valid. 이 기간에 시작되는 트랜잭션은 이 행 버전을 참조할 수 있습니다.Transactions that start in this interval can see this row version. 자세한 내용은 Transactions with Memory-Optimized Tables(메모리 액세스에 최적화된 테이블의 트랜잭션)를 참조하세요.For more details see Transactions with Memory-Optimized Tables.

    인덱스 포인터는 체인에서 해시 버킷에 속한 그 다음 행을 가리킵니다.The index pointers point to the next row in the chain belonging to the hash bucket. 다음 그림에서는 두 개의 열(이름, 도시)이 있는 테이블의 구조를 보여 줍니다. 여기에는 두 개의 인덱스가 있는데, 하나의 이름 열에 대한 것이고 다른 하나는 도시 열에 대한 것입니다.The following figure illustrates the structure of a table with two columns (name, city), and with two indexes, one on the column name, and one on the column city.

    두 개의 열과 인덱스가 있는 테이블의 구조Structure of a table with two columns and indexes.

    이 그림에서는 John과 Jane이라는 이름이 첫 번째 버킷에 해시됩니다.In this figure, the names John and Jane are hashed to the first bucket. Susan은 두 번째 버킷에 해시됩니다.Susan is hashed to the second bucket. 베이징과 보고타는 첫 번째 버킷에 해시됩니다.The cities Beijing and Bogota are hashed to the first bucket. 파리와 프라하는 두 번째 버킷에 해시됩니다.Paris and Prague are hashed to the second bucket.

    따라서 이름에 대한 해시 인덱스의 체인은 다음과 같습니다.Thus, the chains for the hash index on name are as follows:

  • 첫 번째 버킷: (John, 베이징), (John, 파리), (Jane, 프라하)First bucket: (John, Beijing); (John, Paris); (Jane, Prague)

  • 두 번째 버킷: (Susan, 보고타)Second bucket: (Susan, Bogota)

    도시에 대한 인덱스의 체인은 다음과 같습니다.The chains for the index on city are as follows:

  • 첫 번째 버킷: (John, 베이징), (Susan, 보고타)First bucket: (John, Beijing), (Susan, Bogota)

  • 두 번째 버킷: (John, 파리), (Jane, 프라하)Second bucket: (John, Paris), (Jane, Prague)

    종료 타임스탬프 ∞(무한대)는 해당 행이 현재 유효한 버전의 행임을 나타냅니다.An end timestamp ∞ (infinity) indicates that this is the currently valid version of the row. 이 행 버전이 기록되었기 때문에 행은 업데이트되거나 삭제되지 않았습니다.The row has not been updated or deleted since this row version was written.

    200보다 큰 시간의 경우 테이블에 다음 행이 포함됩니다.For a time greater than 200, the table contains the following rows:

이름Name CityCity
JohnJohn 베이징Beijing
JaneJane 프라하Prague

그러나 시작 시간이 100인 활성 트랜잭션은 다음 버전의 테이블을 참조합니다.However, any active transaction with begin time 100 will see the following version of the table:

이름Name CityCity
JohnJohn 파리Paris
JaneJane 프라하Prague
SusanSusan 보고타Bogata

[row body size] 계산은 다음 표에서 설명합니다.The calculation of [row body size] is discussed in the following table.

행 본문 크기는 계산된 크기 및 실제 크기의 두 가지 방식으로 계산할 수 있습니다.There are two different computations for row body size: computed size and the actual size:

  • [computed row body size]로 표시되는 계산 크기는 행 크기 제한인 8,060바이트를 초과하는지 여부를 확인하기 위해 사용됩니다.The computed size, denoted with [computed row body size], is used to determine if the row size limitation of 8,060 bytes is exceeded.

  • [actual row body size]로 표시되는 실제 크기는 메모리 및 검사점 파일에서 행 본문의 실제 저장소 크기입니다.The actual size, denoted with [actual row body size], is the actual storage size of the row body in memory and in the checkpoint files.

    [computed row body size] 및 [actual row body size]는 모두 비슷하게 계산됩니다.Both [computed row body size] and [actual row body size] are calculated similarly. 유일한 차이점은 다음 표의 하단에 표시된 것처럼 (n)varchar(i) 및 varbinary(i) 열의 크기에 대한 계산입니다.The only difference is the calculation of the size of (n)varchar(i) and varbinary(i) columns, as reflected at the bottom of the following table. 계산된 행 본문 크기는 선언된 크기인 i 를 열 크기로 사용하고, 실제 행 본문 크기는 데이터의 실제 크기를 사용합니다.The computed row body size uses the declared size i as the size of the column, while the actual row body size uses the actual size of the data.

    다음 표에서는 [actual row body size] = SUM([size of shallow types]) + 2 + 2 * [number of deep type columns]와 같이 행 본문 크기의 계산에 대해 설명합니다.The following table describes the calculation of the row body size, given as [actual row body size] = SUM([size of shallow types]) + 2 + 2 * [number of deep type columns].

섹션Section 크기Size 설명Comments
단순 형식 열Shallow type columns SUM([단순 형식의 크기])SUM([size of shallow types]). 개별 형식의 바이트 크기는 다음과 같습니다.Size in bytes of the individual types is as follows:

Bit: 1Bit: 1

Tinyint: 1Tinyint: 1

Smallint: 2Smallint: 2

Int: 4Int: 4

Real: 4Real: 4

Smalldatetime: 4Smalldatetime: 4

Smallmoney: 4Smallmoney: 4

Bigint: 8Bigint: 8

Datetime: 8Datetime: 8

Datetime2: 8Datetime2: 8

Float: 8Float: 8

Money: 8Money: 8

숫자(전체 자릿수<=18): 8Numeric (precision <=18): 8

Time: 8Time: 8

숫자(전체 자릿수>18): 16Numeric(precision>18): 16

Uniqueidentifier: 16Uniqueidentifier: 16
단순 열 패딩Shallow column padding 가능한 값은Possible values are:

전체 형식 열이 있고 단순 열의 총 데이터 크기가 홀수인 경우 1입니다.1 if there are deep type columns and the total data size of the shallow columns is as odd number.

그렇지 않으면 0입니다.0 otherwise
전체 형식은 (var)binary 및 (n)(var)char 형식입니다.Deep types are the types (var)binary and (n)(var)char.
전체 형식 열의 오프셋 배열Offset array for deep type columns 가능한 값은Possible values are:

전체 형식 열이 없으면 0입니다.0 if there are no deep type columns

그렇지 않으면 2 + 2 * [number of deep type columns]입니다.2 + 2 * [number of deep type columns] otherwise
전체 형식은 (var)binary 및 (n)(var)char 형식입니다.Deep types are the types (var)binary and (n)(var)char.
NULL 배열NULL array [number of nullable columns]/8, 전체 바이트로 반올림[number of nullable columns] / 8, rounded up to full bytes. null 허용 열당 1비트가 배열에 포함됩니다.The array has one bit per nullable column. 전체 바이트로 반올림됩니다.This is rounded up to full bytes.
NULL 배열 패딩NULL array padding 가능한 값은Possible values are:

전체 형식 열이 있고 NULL 배열의 크기가 홀수 바이트인 경우 1입니다.1 if there are deep type columns and the size of the NULL array is an odd number of bytes.

그렇지 않으면 0입니다.0 otherwise
전체 형식은 (var)binary 및 (n)(var)char 형식입니다.Deep types are the types (var)binary and (n)(var)char.
패딩Padding 전체 형식 열이 없으면 0입니다.If there are no deep type columns: 0

전체 형식 열이 있는 경우, 단순 열에 필요한 최대 맞춤에 따라 0-7바이트의 패딩이 추가됩니다.If there are deep type columns, 0-7 bytes of padding is added, based on the largest alignment required by a shallow column. 각 단순 열에는 위에 설명한 대로 해당 크기와 동일한 맞춤이 필요하지만, GUID 열은 16바이트가 아니라 1바이트의 맞춤이 필요하고, 숫자 열에는 항상 16이 아닌 8바이트의 맞춤이 필요합니다.Each shallow column requires alignment equal to its size as documented above, except that GUID columns need alignment of 1 byte (not 16) and numeric columns always need alignment of 8 bytes (never 16). 모든 단순 열 사이에 가장 높은 맞춤 요구 사항이 사용되며, 지금까지의 총 크기(전체 형식 열 없음)가 필요한 맞춤의 배수가 되도록 0-7바이트의 패딩이 추가됩니다.The largest alignment requirement among all shallow columns is used, and 0-7 bytes of padding is added in such a way that the total size so far (without the deep type columns) is a multiple of the required alignment.
전체 형식은 (var)binary 및 (n)(var)char 형식입니다.Deep types are the types (var)binary and (n)(var)char.
고정 길이 전체 형식 열Fixed-length deep type columns SUM([size of fixed length deep type columns])SUM([size of fixed length deep type columns])

각 열의 크기는 다음과 같습니다.The size of each column is as follows:

char(i) 및 binary(i)의 경우 ii for char(i) and binary(i).

nchar(i)의 경우 2 * i2 * i for nchar(i)
고정 길이 전체 형식 열은 char(i), nchar(i) 또는 binary(i) 유형의 열입니다.Fixed-length deep type columns are columns of type char(i), nchar(i), or binary(i).
가변 길이 전체 형식 열 [computed size]Variable length deep type columns [computed size] SUM([computed size of variable length deep type columns])SUM([computed size of variable length deep type columns])

각 열에 대해 계산된 크기는 다음과 같습니다.The computed size of each column is as follows:

varchar(i) 및 varbinary(i)의 경우 ii for varchar(i) and varbinary(i)

nvarchar(i)의 경우 2 * i2 * i for nvarchar(i)
이 행은 [computed row body size]에만 적용되었습니다.This row only applied to [computed row body size].

가변 길이 전체 형식 열은 varchar(i), nvarchar(i) 또는 varbinary(i) 유형의 열입니다.Variable-length deep type columns are columns of type varchar(i), nvarchar(i), or varbinary(i). 계산된 크기는 열의 최대 길이(i)에 의해 결정됩니다.The computed size is determined by the max length (i) of the column.
가변 길이 전체 형식 열 [actual size]Variable length deep type columns [actual size] SUM([actual size of variable length deep type columns])SUM([actual size of variable length deep type columns])

각 열의 실제 크기는 다음과 같습니다.The actual size of each column is as follows:

n, 여기서 n은 varchar(i)에 대해 열에 저장된 문자 수입니다.n, where n is the number of characters stored in the column, for varchar(i).

2 * n, 여기서 n은 nvarchar(i)에 대해 열에 저장된 문자 수입니다.2 * n, where n is the number of characters stored in the column, for nvarchar(i).

n, 여기서 n은 varbinary(i)에 대해 열에 저장된 바이트 수입니다.n, where n is the number of bytes stored in the column, for varbinary(i).
이 행은 [actual row body size]에만 적용되었습니다.This row only applied to [actual row body size].

실제 크기는 행의 열에 저장된 데이터에 의해 결정됩니다.The actual size is determined by the data stored in the columns in the row.

예제: 테이블 및 행 크기 계산Example: Table and Row Size Computation

해시 인덱스의 경우 실제 버킷 수는 가장 가까운 2의 제곱으로 반올림됩니다.For hash indexes, the actual bucket count is rounded up to the nearest power of 2. 예를 들어, 지정된 bucket_count가 100000인 경우 인덱스의 실제 버킷 수는 131072입니다.For example, if the specified bucket_count is 100000, the actual bucket count for the index is 131072.

다음 정의의 Orders 테이블을 살펴보십시오.Consider an Orders table with the following definition:

CREATE TABLE dbo.Orders (  
     OrderID int NOT NULL   
           PRIMARY KEY NONCLUSTERED,  
     CustomerID int NOT NULL   
           INDEX IX_CustomerID HASH WITH (BUCKET_COUNT=10000),  
     OrderDate datetime NOT NULL,  
     OrderDescription nvarchar(1000)  
) WITH (MEMORY_OPTIMIZED=ON)  
GO  

이 테이블에는 1개의 해시 인덱스와 1개의 비클러스터형 인덱스(기본 키)가 있습니다.Notice that this table has one hash index and a nonclustered index (the primary key). 또한 3개의 고정 길이 열과 1개의 가변 길이 열이 포함되며, 이러한 열 중 하나는 Null 허용으로 구성됩니다(OrderDescription).It also has three fixed-length columns and one variable-length column, with one of the columns being NULLable (OrderDescription). 이제 Orders 테이블에 8379 행이 있고 OrderDescription 열의 평균 값 길이가 78자라고 가정해보십시오.Let’s assume the Orders table has 8379 rows, and the average length of the values in the OrderDescription column is 78 characters.

테이블 크기를 결정하려면 먼저 인덱스 크기를 결정해야 합니다.To determine the table size, first determine the size of the indexes. 두 인덱스의 bucket_count는 10000으로 지정되었습니다.The bucket_count for both indexes is specified as 10000. 이 숫자는 가장 가까운 2의 제곱인 16384입니다.This is rounded up to the nearest power of 2: 16384. 따라서 Orders 테이블에서 인덱스의 총 크기는 다음과 같습니다.Therefore, the total size of the indexes for the Orders table is:

8 * 16384 = 131072 bytes  

남은 것은 테이블 데이터 크기입니다.What remains is the table data size, which is,

[row size] * [row count] = [row size] * 8379  

예제 테이블에는 8379개 행이 있습니다. 이제 다음과 같이 됩니다.(The example table has 8379 rows.) Now, we have:

[row size] = [row header size] + [actual row body size]  
[row header size] = 24 + 8 * [number of indices] = 24 + 8 * 1 = 32 bytes  

그러면 이제 [actual row body size]를 계산해보겠습니다.Next, let’s calculate [actual row body size]:

  • 단순 형식 열:Shallow type columns:

    SUM([size of shallow types]) = 4 [int] + 4 [int] + 8 [datetime] = 16  
    
  • 총 단순 열 크기는 짝수이므로 단순 열 패딩은 0입니다.Shallow column padding is 0, as the total shallow column size is even.

  • 전체 형식 열의 오프셋 배열:Offset array for deep type columns:

    2 + 2 * [number of deep type columns] = 2 + 2 * 1 = 4  
    
  • NULL 배열은 1입니다.NULL array = 1

  • NULL 배열 크기가 홀수이고 전체 형식 열이 있으므로 NULL 배열 패딩은 1입니다.NULL array padding = 1, as the NULL array size is odd and there is a deep type column.

  • 패딩Padding

    • 가장 큰 맞춤 요구 사항은 8입니다.8 is the largest alignment requirement.

    • 지금까지 크기는 16 + 0 + 4 + 1 + 1 = 22입니다.Size so far is 16 + 0 + 4 + 1 + 1 = 22.

    • 8의 가장 가까운 배수는 24입니다.Nearest multiple of 8 is 24.

    • 총 패딩은 24 - 22 = 2바이트입니다.Total padding is 24 – 22 = 2 bytes.

  • 고정 길이 전체 형식 열은 없습니다(고정 길이 전체 형식 열은 0임).There are no fixed-length deep type columns (Fixed-length deep type columns: 0.).

  • 전체 형식 열의 실제 크기는 2 * 78 = 156입니다.The actual size of deep type column is 2 * 78 = 156. 단일 전체 형식 열 OrderDescription의 형식은 nvarchar입니다.The single deep type column OrderDescription has type nvarchar.

[actual row body size] = 24 + 156 = 180 bytes  

계산을 완료하면 다음과 같습니다.To complete the calculation:

[row size] = 32 + 180 = 212 bytes  
[table size] = 8 * 16384 + 212 * 8379 = 131072 + 1776348 = 1907420  

메모리에서 총 테이블 크기는 약 2MB입니다.Total table size in memory is thus approximately 2 megabytes. 여기에는 메모리 할당으로 발생하는 잠재적인 오버헤드와 이 테이블에 액세스하는 트랜잭션에 필요한 행 버전 관리가 고려되지 않았습니다.This does not account for potential overhead incurred by memory allocation as well as any row versioning required for the transactions accessing this table.

이 테이블 및 해당 인덱스에 할당되어 사용되는 실제 메모리는 다음 쿼리를 통해 얻을 수 있습니다.The actual memory allocated for and used by this table and its indexes can be obtained through the following query:

select * from sys.dm_db_xtp_table_memory_stats  
where object_id = object_id('dbo.Orders')  

행 외부 열 제한 사항Off-row Column Limitations

메모리 최적화 테이블에 행 외부 열을 사용할 경우의 특정 제한 사항 및 유의 사항은 다음과 같습니다.Certain limitations and caveats to using off-row columns in a memory-optimized table are listed below:

  • 메모리 최적화 테이블에 대한 columnstore 인덱스가 있는 경우 모든 열이 행 내부에 맞아야 합니다.If there is a columnstore index on a memory-optimized table, then all the columns must fit in-row.
  • 모든 인덱스 키 열은 행 내부에 저장되어야 합니다.All index key columns must be stored in-row. 인덱스 키 열이 행 내부에 맞지 않을 경우 인덱스를 추가하지 못합니다.If an index key column doesn't fit in-row, adding the index fails.
  • 행 외부 열이 있는 메모리 최적화 테이블을 변경할 경우의 유의 사항입니다.Caveats on altering a memory-optimized table with off-row columns.
  • LOB에 대한 크기 제한 사항은 디스크 기반 테이블의 크기 제한 사항을 미러링합니다(LOB 값에 대한 2GB 제한).For LOBs the size limitation mirrors that of disk based tables (2GB limit on LOB values).
  • 성능을 최적화하려면 대부분의 열을 8060바이트 이내로 설정하는 것이 좋습니다.For optimal performance, it is recommended to have most columns fit within 8060 bytes.

What's new for In-Memory OLTP in SQL Server 2016 since CTP3(CTP3 이후 SQL Server 2016의 메모리 내 OLTP에 대한 새로운 기능) 블로그 게시물에서 이러한 몇 가지 복잡한 사항을 자세히 설명합니다.What's new for In-Memory OLTP in SQL Server 2016 since CTP3 blog post further details some of these intricacies.

관련 항목:See Also

메모리 액세스에 최적화된 테이블Memory-Optimized Tables