既然同一行在内存中存在这么多的行版本，那数据库在访问时是怎么控制的呢？
在传统数据库中，表中每一行都是唯一的，一个事务如想找到一行，通过文件号、页号、槽位就可以了。
在内存数据库中，每一行有多个行版本，一个事务不可能对将每个行版本都操作一遍，实际上，一个事物只能操作同一行的一个行版本，至于它能对哪个行版本进行操作，取决于事务执行时间是否在这行的两个时间戳之间。除此之外的其他行版本对该事务而言是不可见的。
由于一行可能存在多个行版本，大家可能会提出这样一个疑问：每行都有这么多行版本，一张上百万行的表，内存哪够呀。不用担心，前文介绍过了，每个行实际上是有时间戳的，对于已经打上结束时间戳且没有活动事务访问的行，SQL Server会通过garbage collection机制回收它占用的内存，从而节省内存。所以不要担心内存不够。
四、内存数据库号称无锁式设计，那如果发生了并发冲突怎么办，SQL是如何处理冲突的呢？
答案：内存数据库用行版本来处理冲突。
锁的一个重要作用就是避免多个进程同时修改数据，从而造成数据不一致。常见的冲突现象包括读写互锁和写写互锁。那内存数据库是如何通过行版本来解决这两种锁定现象的呢？
（1）读写互锁
在内存数据库中，所有对内存优化表的事务隔离都是基于快照的，准确的说是基于行的快照。从上文行的 结构可以知道，每行的行头包括开始时间戳和结束时间戳的，一个事务能不能访问到这行关键在于事务的启动时间是不是在这行的两个时间戳内。
如果某个事务正在修改一行（快照），但还未提交到内存优化表中，也就是说"新行"还没有结束时间戳，对"读事务"而言，它读还是是原来行（快照），因此不会存在脏读的现象。
（2）写写互锁
两个事务同时更新一行时，就会发生写写互锁。
内存数据库冲突发生的概率比传统数据库小很多，但如果实在遇到了冲突，只能调整应用程序，在应用程序中加入"重试逻辑"（等待一会，然后再重新发起事务）来解决。
或许有同学觉得这种方式好像也没有什么大的性能改变。其实不然，举个例子，在传统数据库中一个锁可能将整个表都管住了，在表锁期间只能等待这个事务做完才能执行其他事务，而实际上这个事务可能只是修改了小部分行，因为表锁的存在，其他行那些不需要被这个事务操作的行。但内存数据库中写写冲突总是发生在行级别的，这个粒度小多了，影响没这么大。
