对内存表的测试发现的问题

Question

 1、使用TSQL如 insert update delete ,操作内存表比操作磁盘表要略慢一些
 2、 如果使用本地编译的存储过程进行操作，与操作磁盘表相比：select操作几乎差不多，一条一条的对表中的数据进行insert update delete却有非常绝对的优势

 3：使用c#写了一个并发测试程序，同时打开10000个线程，SQL里面是一条update语句，对表中仅某一行进行修改操作，结果发现：
       对磁盘表操作明显快于本地编译的存储过程的内存表操作，而且后者还会约有5%的失败率，因为采用乐观控制原理，将被回滚，而不是磁盘表那种阻塞 对于这种劣势，某些业务的确是存在的，如：大量用户看同一种商品，而且又不能容忍延时的话，就会存在这种需求，那么如何解决呢，如果内存表不能解决这种类似的问题，我觉得也有很大的遗憾

     还有一点：5%的失败率说明争用并不是很强，不应该比磁盘表的操作慢才对赛，这是为何呢？

Answer 1

How did you set memory residence table? How did you set logging? How much memory allocated to sql?

Answer 2

哈哈哈，这么复杂！

bucket_count=1000000 ,但是 插入的数据仅仅10w条

全部采用的是持久化的内存表！

Answer 3

要理解内存表是hash而不是b+ tree。另外，idu也是要写日志文件的（非持久化不写）。

失败了要考虑retry。

你的并发测试是对同一行修改操作吗？

bucket_count=1000000 ，内存足够用吗？

---

想不想时已是想，不如不想都不想。

Answer 4

最好把你的测试表结构和更新语句都贴出来，随机更新，还是更新同一条，考虑的因素是不一样的，表的数据量大时的随机更新和小表的随机更新考虑的因素也不一样

“%的失败率说明争用并不是很强” 这个理论不成立， 失败和争用不能划等号，合理的加锁，执行超时够长，则并发不会失败，只是在等待，不能说明并发不强