先说背景：某日我测试时一下子删了很重要的东西，一篇重要的文章，立即后悔了，但是却发现没有“回收站”，数据表是直接物理删除的，我的内心是崩溃的……
此后无论做什么，我都会记住这个深刻的教训，给自己留一颗后悔药，总会在建表时留一个is_del字段以表示是否被删除了……，所有的删除不直接物理删除，然后我就很嘚瑟，再也不怕误删了……
但是现在碰到了一个麻烦，某个字段是唯一索引的，而我暂时不想用这个数据就把它删了，当然不是真删了，用is_del标示而已，但是问题就是我现在要添加的一个数据和这个“被删除”行里面的唯一字段重复了，导致我现在如果不真的把那个删了的话我就添加不了这行数据了。
我想到了两个解决办法：不知道合不合理：
1：删除时将要删除的数据“剪切”到另外一张“回收站临时表”
2：只剪切要删除的行的部分数据，比如上文中的唯一索引那个字段，将当前的冲突字段数据擦除，放到另外一张临时表上面，用主键对应就可以了。
我总觉得是不是我的想法有问题，总感觉欠妥，但又不知道怎么做，希望有经验的大神解答指点下哈？
如果不嫌麻烦就做个日志系统，所有增删改的数据都写入日志，然后如果有误操作再根据日志做回滚操作
如果要足够优化的解，那自然是移到其他表去，这样既不妨碍当前表数据，又利用当前表高效的工作。
如果图方便，可以弄个组合索引，将is_del也纳入其中。
亲，windows系统的回收站难道避免了误删重要文件的结局吗？
我觉得你想的太多了，从你的故事背景就可以看出来你的立场出了问题。作为一个开发人员，你需要满足客户的要求，比如删除文章这种事情根本不是你应该做的，如果用户自己删错了东西他自己去后悔，和你有什么关系？就像咱们在这里发东西，删掉之后能找回来吗？开发人员需要为此负责吗？
日志其实是很重要的东西，但是通常使用日志不是为了找回数据，而是为了分析问题，实际上mysql本身也可以开启日志，那个可以帮助你找回数据，为什么要在php上重新搞一遍呢？
所以，我的看法是除非客户说：我们使用的时候经常删错东西，别做物理删除了，这个时候才需要考虑is_del这种方法。但是一般也要讲清楚，使用这个方式之后数据就永远不会删除了，千万别说还有一个功能可以把标记为is_del的数据真正删除，那还是解决不了经常删错东西问题。
程序不可能解决使用者犯下的错误，所以根本没必要想太多。对于有些人来说，就算你设计了is_del1,is_del2,is_delN，错删数据的事情还是会发生。
放到另一张表里边吧，保险，而且当你查询删除数据的时候可能速度会快一些。不过我感觉放到临时删除表的时候，id应该重建了，不然你再删除相同id的数据，麻烦还是会出现。
一般情况下 唯一索引 只能给id nickname 之类的字段
一条记录is_del的时候id nickname 之类的被使用了就是被使用，不应该再出现，拿nickname来说，这条记录被删除，应该被当作封禁而不是常规的删除，某个nickname被删或者被封禁以后这个字段不应该再被拿出来使用。
删除的时候先把这个记录复制到到回收站`被删除数据备份`表可以做，但是更好的做法应该是处理你的唯一索引，确定你这个字段是否真的需要唯一索引
建表的时候保留is_delete字段是一个很好的习惯。
按照你说的，你删除数据后，又要添加一个和已经删除记录的唯一索引字段相同的记录，可见你已经删除的记录在业务中应该不会在用到了。
我想到的解决方法是：
1.将唯一字段和is_delete字段一起设置成唯一索引，这种加入后面需要将删除的记录恢复使用很容易处理；
2.在插入唯一重复的记录时，将删除的记录移到history表中，这种原表更简单，不过后面要恢复以前的记录有点麻烦；
3.如果插入唯一重复记录的情况比较多，建议直接采取删除时候就移到history表中，这样插入的时候方便。