none
测试内存优化表发现的问题 RRS feed

  • 问题

  • 采用c#客户端程序,并发20000个线程去连接数据库,分别执行两个存储过程,一个是修改磁盘表的update操作,每次只修改一行,用多线程传入的参数使得每次修改的行都不相同(CPU可以压到90%多),另一个存储过程与前一个存储过程是一样的,只不过采用的是本机编译的存储过程从而修改内存表(CPU只能压到70%多)

    最后发现:采用本机编译的内存表的修改明显慢与磁盘表的修改好几秒,如果不采用本机编译的存储过程,而使用不同存储过程修改内存表,更慢

    但是,如果不是update而是select,每次获取的结果都为一条,两个存储过程所化时间几乎相同

    如果不是并发操作,而是用一个存储过程里面循环20000次去update,本机编译的存储过程+内存表相比普通的存储过程——硬盘表占有绝对优势

    所以:我觉得内存表怎么在并发量大的情况下这么差呢

    2015年3月26日 3:39

全部回复

  • Which sql version do you use? SQL2014 in-memory table?
    2015年3月26日 13:24
  • 请问楼主可以给出对比数据吗

    比如

    测试组一

    内存表+native sp   xx 时间

    普通表+普通 sp xx时间

    测试组二

    内存表+native sp   xx 时间

    普通表+普通 sp xx时间

    这样才能更直观的去判断,还有最好也附上测试代码

    原理

    native sp 之所以快是因为他不需要编译,可以想象成你写C#代码一样,你的代码如果要用VS编辑,然后运行那个生成出来的exe是不是更慢了,如果本身不需要编译你的代码,而可以执行就执行exe 是不是更快了

    内存表:最要优势就是flush 日志 ,不知道楼主的配置是怎样的,希望楼主可以给出建表语句


    Love SQL


    2015年3月26日 14:26
  • 对,是SQL2014 in-memory table!
    2015年3月27日 1:19
  • Native compiled sp has potential performance issue, optimizer generates execution plan based on stats when create the sp. If involved table has many data changes, cached plan maybe not optimize anymore. Bad news is that you can't recompile native compiled sp to generate new plan, have to recreate the sp. 
    2015年3月27日 2:37