高并发select的问题
各位大神，最近接手改造一个原生jdbc的java项目，把一张表里的记录按顺序拿出来去做操作，操作之后更新标志位，接着读取下一条，开一两个进程还可以，同时并发40个操作就出问题了，有1/4的进程读取的是同一条记录，select.....for update加锁了，加锁只是避免了更新，但是避免不了读取，有10个进程同时读取一条记录，1个锁行，另外9个还会等待，这个时间老板还是接受不了......
最期望的是40个并发能够顺序的沿着表向下读，而不用等锁，求各位大神指点啊！！急求！！
[解决办法]
这个和Select有什么关系？
锁的不是Select，而是Update。
如果没理解错，LZ每次Select后都会去Update原表
除非你用了排它锁，更新锁不会阻止SELECT，在大并发的情况下，后面的Update才会被锁。
这种情况只有改变业务结构，Select之后不要立刻Update，而是Insert状态到一张Log表。
Log表的数据异步更新原表的数据
[解决办法]
采取批量更新，1000条一次
批量更新的方法同步，不考虑数据层面锁
[解决办法]
for update 悲观锁，这不会阻塞读，只能阻塞写
如果你一定要按顺序执行，我和你说了，不要在数据库层面考虑锁，在程序层面同步，数据你采用批量方式，不能逐行更新，这样保证了你数据不可能重复读，性能也不会太低
[解决办法]
1， 能不能把处理逻辑放在store procedure去处理
2， 循环里面批量更新
3， 不要用悲观锁， 对oracle来说读是不阻塞更新的，sqlserver以前版本是有这情况，现在不清楚。
[解决办法]
我也认为不应该在数据库层面做 你可以考虑分批读数据到Java 安全队列中处理 这样就不会多个线程同时处理同一条数据了
[解决办法]
可以分布，一个线程去查记录，40个线程处理记录。这样不会有问题。
[解决办法]
表中有没有唯一的标识? 如果有序列最好了,你可以启10个进程,第1个进程取所有标识尾数为1的,第10个进程取所有标识尾数为0的,...以此类推,或者取摩运算. 总之让你的进程不会同时取同一条记录.
[解决办法]
跟select没关系吧？
建议如下：
1、数据表做分区
2、数据库做读写分离
[解决办法]
LZ可以考虑下9L的方法
