Merge pull request #21191 from WilliamAntonRohm/issue-7278

sql-docs/issues/7278 -- typo

Author: PRMerger19

docs/sql-server/maximum-capacity-specifications-for-sql-server.md

@@ -49,7 +49,7 @@ Maximum sizes and numbers of various objects defined in [!INCLUDE[ssNoVersion](.
 |Bytes per short string column|8,000||
 |Bytes per `GROUP BY`, `ORDER BY`|8,060||
 |Bytes per index key|900 bytes for a clustered index. 1,700 for a nonclustered index. Before SQL Server 2016, all versions supported 900 bytes for all index types.|The maximum number of bytes in a clustered index key cannot exceed 900 in [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)]. For a nonclustered index key, the maximum is 1700 bytes.<br /><br /> You can define a key using variable-length columns whose maximum sizes add up to more than the limit. However, the combined sizes of the data in those columns can never exceed the limit.<br /><br /> In a nonclustered index, you can include extra non-key columns, and they do not count against the size limit of the key. The non-key columns might help some queries perform better.|
-|Bytes per index key for memory-optimized tables|2500 bytes for a nonclustered index. No limit for a hash index, as long as all index keys fit in-row.|On a memory-optimized table, a nonclustered index cannot have key columns whose maximum declared sizes exceed 2500 bytes. It is irrelevant whether the actual data in the key columns would be shorter than the maximum declared sizes.<br /><br /> For a hash index key, there is no hard limit on size.<br /><br /> For indexes on memory-optimized tables, there is no concept of included columns, since all indexes inherently cover of all columns.<br /><br /> For a memory-optimized table, even though the row size is 8060 bytes, some variable-length columns can be physically stored outside those 8060 bytes. However, the maximum declared sizes of all key columns for all indexes on a table, plus any additional fixed-length columns in the table, must fit in the 8060 bytes.|
+|Bytes per index key for memory-optimized tables|2500 bytes for a nonclustered index. No limit for a hash index, as long as all index keys fit in-row.|On a memory-optimized table, a nonclustered index cannot have key columns whose maximum declared sizes exceed 2500 bytes. It is irrelevant whether the actual data in the key columns would be shorter than the maximum declared sizes.<br /><br /> For a hash index key, there is no hard limit on size.<br /><br /> For indexes on memory-optimized tables, there is no concept of included columns, since all indexes inherently cover all columns.<br /><br /> For a memory-optimized table, even though the row size is 8060 bytes, some variable-length columns can be physically stored outside those 8060 bytes. However, the maximum declared sizes of all key columns for all indexes on a table, plus any additional fixed-length columns in the table, must fit in the 8060 bytes.|
 |Bytes per foreign key|900||
 |Bytes per primary key|900||
 |Bytes per row|8,060|[!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)] supports row-overflow storage, which enables variable length columns to be pushed off-row. Only a 24-byte root is stored in the main record for variable length columns pushed out of row. This feature allows limit that is effectively higher than in previous releases of [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)]. For more information, see [Large Row Support](../relational-databases/pages-and-extents-architecture-guide.md#large-row-support).|