insert 重复插入问题

1.select for update
2.用唯一
3.为啥邮箱和性别要唯一？

上事务

数据库事务和锁？

加唯一键

上分布式锁。

@nybux 这里不是 update 操作啊

@GDC 目前我们是做了唯一索引，还有方法加了 sychnazed，但这不是最优方案啊。

你的隔离级别设的是啥

@nybux 这里只是举这么一个例子。实际情况，不是这两个条件。

@liprais 感觉跟隔离级别没有太大关系，主要是两台机器同时 select 了一样的结果出来

@wmhack
....for update 是锁,看来你一点不懂 sql

1. 加个 requestid 从前端到后端做锁
2. 几个唯一条件联合做锁，如 redis

@id4alex 事物也控制不了同时 select 呀

@wmhack

上事务 加上 insert tablename select 'col1' as col1, 'col2' as col2 from 伪表 where not exist select 1 from tablename where your condition

这加个 unique key 就能解决的吧。

前面也不用判断 RS == null 了， 直接执行这个 SQL 就可以了

加了唯一索引 就不会两条都插入了

唯一索引

唯一所以 可以避免两次插入，第一次插入成功了，第二次就出错了。 也就无需 select 了，直接干

@ThirdFlame 是的，这是第二重限制。但报错的方式有时也不太好，如果没有更好的方案，那就只能靠唯一索引去控制了

@id4alex 我们是 oracle 数据库，类似这种 insert 时 where 的语句当时试过，mybatis 会报错，所以当时就放弃了

有很多解决方案，根据你实际项目资源和项目阶段选择：
1、上唯一索引，只要有 1 条完成插入后第二条再次插入就会报错。
2、利用 rides、zookeeper 等第三方分布式 k-v 存储制造分布式锁，利用分布式锁完成插入。
3、将所有写操作集中到同一进程，入列后等待完成。

最简单最便宜的是 1，但是这样你要拦截错误后自行处理，代码逻辑复杂度升高。
接下来是 3，但是如果采用方案 3 当你的写入队列进程挂掉或阻塞的时候会引起服务不可用。
2 是时下主流解决方案，但是投入资本最高，开发难度也较高。

想到个奇怪的思路，大佬们评估下可行性
1. 正常插入，插 2 条就 2 条吧
2. 查询的时候，控制以 id 小的为准 order by id limit 1
3. （可选）定期洗理重复且 id 大的数据

设置好唯一索引，然后插入语句改为 insert into on duplicate update，这样即使数据重复插入也只是更新而已。

不想在数据库做处理就用分布式锁，或者吧这个 insert 动作丢给队列。一个一个处理

1. 插入前锁全表 开发成本最低，但是数据库开销最大并且有可能会影响业务 如果业务无所谓这种方法最合适
2. 设置一个唯一索引 开发成本低但是数据库开销大，如果本来就有一个字段需要加索引这种方法最合适
3. 用 redis 等缓存做分布式锁，拿到锁的进程 insert 别的进程返回。开发成本适中，反正分布式锁你后你也会用的。
4. 消息队列，直接把 insert 操作扔进去 消费者来做就行了。但是开发成本很高了。
5. 分布式事务 这种成本最高 了解一下就 OK

幻读，事务调到 SERIALIZABLE 级别

都跟你说了 select for update。不存在会锁住的

select lock in share mode 就行了吧。

@xomix 这些方案感觉可行的，很好的一些建议

@dilu 这些思路很好，感谢了

哪位大神如果有更好的方案，欢迎提出来额。大伙表示感谢啦

在同个事务下，select for update 会用 next-key lock 锁住索引不让插入

重复提交问题，把请求的参数 md5 后存到 redis，然后设置一个超时时间，第二次来了从 redis 中先判断是否有现在的 md5 值有就判断为重复提交，没有就通过

思路都差不多，在客户端和数据库中间加一层中间件做控制。锁的实现最好避免在数据库端实现，利用 redis/MQ 实现，实现高效的锁。

INSERT IGNORE . 直接忽略后面的插入操作。 但是这种操作不是很严谨，个人还是比较倾向于使用队列