redog

另外你的类型不一致，要进行一次手动转换，不然还是会回到 DEPENDENT SUBQUERY ，具体的话，你应该试试:
SELECT software_id from software where author_id = 1 and CONVERT(software_id,char) not in ( select software_id FROM company_software WHERE author_id = 1 and country in ('china', 'korea', 'england') )
这样在 mysql 看来子查询是独立于主查询的，这样只会执行一次子查询，上面都使用了索引，如果你不使用 convert 去转换，因为类型不一致，mysql 又会先看 author_id 有多少条，有多少条就执行多少次子查询，这样就慢了。

如果我没有弄错的话 是因为 NOT EXISTS 的原因，这里会导致你最后一个 where CONVERT(sortware.software_id , char) = company_software.software_id 这个是无效的，因为在 mysql 看来，这里不用专门去匹配，直接按前面的条件取回 N 条记录，在这 N 条记录里去检查 software_id 就行了。

这样会导致外层查询时子查询里返回的不是一条记录，而是一堆记录，在这一堆记录里去判断 software_id 是否相等，应该试试用 not in 本质是 inner join 这样会先按索引来一次性筛选，而不是每一条都要去筛选。

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

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

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

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

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

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

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