redog

@shrugginG 客气，这个 exists 使用时得考虑相关表里记录的多少，而且有时你以为它会走索引，结果语句你没写好，它就不按你想要的走索引，我一般无脑用 in ，不差那点性能，至少不会出现死活不走索引这种现象。

如果我没弄错的话，原因是你的 exists 语句，这里的逻辑是用 phishy_urls 表（外表）里的"每一条"url_sha256 去比对插入后的值（内表），所以每一次插入都要用 phishy_urls 表里已有的 10W 多条记录去逐一对比，这个时候我记得是外表索引无意义所以变成了全表扫描。
话说，你用 in 来判断就没这问题，或是你反过来用 NEW 来做外表。
你修改后，用了专属的 ON DUPLICATE KEY UPDATE 本来就是优化后的语句自然不存在这个问题。

会不会是 TDSQL 在你建表用了 unique 索引时，把这个当聚簇了？
你要不重建一张表，什么索引也不用，就把 ID 设置成主键，然后把原表的数据插入再试试？

@BeijingBaby 你这不是有一定的证据，你只要诱导他说出来是因为这个原因来报复就可以继续申诉吧，当然对方可能会装傻，说实话，这种真没什么好的办法。
就算你不让同样的 ID 下单多个地址，他一样弄些小号来差评。
你也可以报案或是起诉，然后拿公家的判决去申诉，这个时间成本就高了而且需要牵扯的金额较高才行。

@zictos 我没弄错的话，主要是这个会有个评分机制在里面，不是说后面的买家相信商家的留言解释就没事了。

我理解的是不能，除非你再买一块盘。或是备份完数据，重做阵列。

确实需要补充证据，简单的说用账号代购是允许的，除非你们自己限制每个 ID 只能购买多少。
那么评价也是如此，你能证明这不是真实用户给代购反馈的真实评价吗？不能吧，如果说你认为是恶意评价，动机在哪儿？你们可以继续跟这个黄牛沟通啊，包括但不限于录音等，让他说出自己是故意恶评。
说实话，对方也完全可以用一堆京东账号来下单（专业的黄牛不可能只有一个账号），然后单单差评。

法律上的风险是先看项目本身是否违法，或是是否帮助了违法份子，这个是后期出事后叔叔来认定的，你说了不算，律师说了都不一定算。
然后本身来说使用个人收款码的风险就是会被微信风控，特别是新号，一有异常你得不停的申请解封，如果你的项目对收款和转账的及时性有要求，这点要注意。
如果你愿意被抽成，找三方的聚合码来办理，稳定性更高一些，就是抽成相对于微信来说是较高的。