请问哪位有使用SQL SERVER2014内存表实际应用经验

[B1U10]

最近在我本机PC电脑上做了SQL SERVER2014内存表测试，测试结果根本内存表相比普通表没任何优势，甚至比普通表更慢，麻烦哪位有实际应用经验，帮忙指点下，到底哪里出问题。
我做的测试很简单，就是新增插入和查询，内存表创建代码：

CREATE TABLE [dbo].[TB_DATA_INDEX_RT1]
(
	[DATA_ID] [bigint] IDENTITY(1,1) NOT NULL,
	[INDEX_CODE] [int] NOT NULL,
	[INDEX_VALUE] [float] NOT NULL,
	[RTIME] [datetime2](3) NOT NULL,
	[VALUE_STATUS] [tinyint] NOT NULL,

 PRIMARY KEY NONCLUSTERED HASH 
(
	[DATA_ID]
)WITH ( BUCKET_COUNT = 33554432)
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )

GO

新增插入时，普通表和内存表基本差不多，每插入一条记录需要8毫秒的样子














查询对比时，内存表I/O确实没有了，但是CPU比普通表高了N倍，所耗时间也比普通表更长

[B1U10]

进一步测试，内存表的优势还是体现出来了。测试过程如下：

[POM_24]

理论上，数据库数据空间有多大，我们的内存表就可以存储多大的数据，就是说 他和我们的物理表是相同的，我们可以把物理表的数据完全拷贝到内存表中。 insert 插入时候，你是通过while循环一条一条从内存到物理存储的，所以相差时间不大；建议楼主可以实验一下批量插入， insert into a select b; 从b 表批量插入a表（内存表&&实体表） select查询时候， 你是批量查询，内存表有优势，不需要扫描物理磁盘，实体表需要先把数据copy到内存。

[B1U10]

引用 4 楼 POM_24 的回复:

你这数据量太少的原因吧，体现不出优势，你整个10W条以上的数据查询呢？

我那里有69W多条记录了。。。。

[B1U10]

引用 5 楼 jycjyc 的回复:

1.好像内存表要配合原生存储过程代码T-SQL才能提高性能效率吧？ 2.当你的数据delete后，看看您内存优化文件组大小是否可以收缩？我以前测试文件组目录一直在增大，无法收缩。

这点没仔细测试，好像是没有收缩！！

[B1U10]

进一步做测试，感觉内存表根本没什么优势，甚至连普通表都不如，比如下面的查询。现在两个表TB_DATA_INDEX_RT2和TB_DATA_INDEX_RT1都是有699986条记录，其中TB_DATA_INDEX_RT1是内存表，TB_DATA_INDEX_RT2是普通表

[POM_24]

你这数据量太少的原因吧，体现不出优势，你整个10W条以上的数据查询呢？

[好记忆不如烂笔头abc]

1.好像内存表要配合原生存储过程代码T-SQL才能提高性能效率吧？ 2.当你的数据delete后，看看您内存优化文件组大小是否可以收缩？我以前测试文件组目录一直在增大，无法收缩。

[wwfxgm]

内存优化表。要使用很不容易的。学习的代价大大增加。 而且内存优化表还达不到和普通表操作那么简单方便。

[吉普赛的歌]

以前测试过一下， 供你参考： http://blog.csdn.net/yenange/article/details/32705347 这个还是非常不错的， 只是你没有用本地编译的存储过程， 所以体现不出来。 几点建议： 1. 单独为内存优化表准备一个数据库， 最好单独一个服务器或者实例. 2. 如果你的数据不太重要， 而对性能要求非常高， 可以用 SCHEMA_ONLY （不做持久化保存到硬盘）， 这个的效率更高。

[B1U10]

引用 10 楼 yenange 的回复:

以前测试过一下， 供你参考： http://blog.csdn.net/yenange/article/details/32705347 这个还是非常不错的， 只是你没有用本地编译的存储过程， 所以体现不出来。 几点建议： 1. 单独为内存优化表准备一个数据库， 最好单独一个服务器或者实例. 2. 如果你的数据不太重要， 而对性能要求非常高， 可以用 SCHEMA_ONLY （不做持久化保存到硬盘）， 这个的效率更高。

谢谢了。。。

[B1U10]

引用 10 楼 yenange 的回复:

以前测试过一下， 供你参考： http://blog.csdn.net/yenange/article/details/32705347 这个还是非常不错的， 只是你没有用本地编译的存储过程， 所以体现不出来。 几点建议： 1. 单独为内存优化表准备一个数据库， 最好单独一个服务器或者实例. 2. 如果你的数据不太重要， 而对性能要求非常高， 可以用 SCHEMA_ONLY （不做持久化保存到硬盘）， 这个的效率更高。

这里还有一个新问题： 本地编译的存储过程只能针对内存表使用，但是实际情况下，一个存储过程不可能只操作内存表，需要做很多业务处理，本地编译的存储过程就没法用上了。。。

[吉普赛的歌]

引用 12 楼 B1U10 的回复:

这里还有一个新问题： 本地编译的存储过程只能针对内存表使用，但是实际情况下，一个存储过程不可能只操作内存表，需要做很多业务处理，本地编译的存储过程就没法用上了。。。

内存优化表不是万能钥匙， 解决不了你的所有问题。
与其追求高大上， 不如把现有的问题解决。
90%的脚本是可以优化的， 你可以在生产环境， 如下图开启性能和监视器， 查到哪些SQL是消耗比较大的， 自己能调整的先调整， 不能的发上论坛大家帮你优化。

[B1U10]

引用 13 楼 yenange 的回复:

[quote=引用 12 楼 B1U10 的回复:] 这里还有一个新问题： 本地编译的存储过程只能针对内存表使用，但是实际情况下，一个存储过程不可能只操作内存表，需要做很多业务处理，本地编译的存储过程就没法用上了。。。

内存优化表不是万能钥匙， 解决不了你的所有问题。 与其追求高大上， 不如把现有的问题解决。 90%的脚本是可以优化的， 你可以在生产环境， 如下图开启性能和监视器， 查到哪些SQL是消耗比较大的， 自己能调整的先调整， 不能的发上论坛大家帮你优化。 [/quote] 谢谢，目前还没用上SQL SERVER，仅仅是做数据库选型的，SQL SERVER2014有内存表，所以想测试下内存表到底能达到什么效果，看看是否能达到工业实时数据库的性能！

[吉普赛的歌]

引用 14 楼 B1U10 的回复:

谢谢，目前还没用上SQL SERVER，仅仅是做数据库选型的，SQL SERVER2014有内存表，所以想测试下内存表到底能达到什么效果，看看是否能达到工业实时数据库的性能！

提高最大的是 dml (增，删，改) 性能， 查询什么的， 要优化SQL、增加合适的索引等来改善

[好记忆不如烂笔头abc]

引用 8 楼 B1U10 的回复:

[quote=引用 5 楼 jycjyc 的回复:]
1.好像内存表要配合原生存储过程代码T-SQL才能提高性能效率吧？
2.当你的数据delete后，看看您内存优化文件组大小是否可以收缩？我以前测试文件组目录一直在增大，无法收缩。

这点没仔细测试，好像是没有收缩！！ [/quote]
这就是一个很大的问题，如果业务量大，担心将来膨胀到无法处理！这点不清楚微软方面有没有明确的文章解释处理。所以一直也不敢用。
以前发过这个http://bbs.csdn.net/topics/392016219

[Tiger_Zhao]

[Quote=引用 10 楼 yenange 的回复:]以前测试过一下， 供你参考：
http://blog.csdn.net/yenange/article/details/32705347
----
内存表比磁盘表快的原理
1. 内存读取比磁盘读取快；
2. 取消了锁，采用行版本机制，读取和更新不冲突。[/Quote]
数据库在读写性能上的优化已经够好了。
普通表也会进行缓存，内存够大（或者说数据量小）的话，频繁操作也是缓存中读写。
内存优化表并不是纯粹的“内存表”，持久表（SCHEMA_AND_DATA）本来就要写硬盘；如果内存不够（或者说数据量大）的话，非持久表（SCHEMA_ONLY）也要写入tempdb。
所以单纯测增删改查的性能，普通表和内存优化表应该差别不会很多，原理1作用不明显。

倒是原理2很有用，多用户下的锁冲突是影响性能的主要因素。
类似买火车票这种高并发高冲突的应用，可以直接避开锁的等待，立即对记录的数据进行判定。

[LongRui888]

内存表是把所有数据都存在内存，所以有个条件就是你的内存要很大，另外，数据量大了，才能体现出他的性能优势，总单条数据上，可能优势不大，但是如果数量量大了，这个优势就出来了，这就是杠杆效应，积少成多，但是数据量一大，对内存的需求就会很大，我感觉用这个内存表，还不如直接用redis来的好。