这种情形可用读写分离吗
业务里有一张表，会有每秒300次的写（每条记录不大），然后会有读。这个数据最多保留1个月，就是说不会无限大下去。
感觉抛开并发读，这种写速度完全没问题吧。本来想采用分库，把这些数据分到不同数据库，但是这样需要程序做适应，而且有个疑问，分库的话，虽然写压力下降了，但是还是会存在读写并发的问题吧。
[解决办法]
1、允许脏读(nolock)。
2、建立相应的索引，提高读的速度
[解决办法]
如果仅是这一个表的负荷，查询不是太频繁，普通设计就可以了
如果真的很大，上SQL 2012 AlwaysOn
[解决办法]
虽然写压力下降了，但是还是会存在读写并发的问题吧
根据业务逻辑分库读写并发的情况会缓解的，因为并发量少了，根据逻辑不同访问不同的表。
[解决办法]
#1.在写速度可以保证的前提下优化读
1.业务允许情况下，加WITH(NOLOCK)，防止读阻塞写
2.读和写都要加合适的索引。因为UPDATE,DELETE操作也是先读后写
#2.如果瓶颈在写操作上
1.加合适的索引
2.保证总体数据量小
#3.如果写速度有保证，加上#1中的优化还是存在瓶颈，考虑用Replication做读写分离。由于Replication靠的是日志，所以不会对现有的写产生大的性能影响
