mysql数据库删除语句怎么写

MySQL为什么不推荐使用in

解决MySQL中IN不走索引问题的方法mysql中in不走索引

说实话，我曾经多次面临过IN没有被索引的问题，而且相当烦人。
这并不意味着如果参数很多就必须扫描整个表，但这种情况确实存在。
你提到的四种方法都是可靠的。
让我补充一些个人经历​​：
1 关于调整参数 我尝试过 innodb_stats_on_metadata=0，尤其是当表结构移动时。
这是一个大型电子商务公司的案例。
表中有数百万条数据。
每次更新索引数据都需要花费大量时间。
后来这个参数改了，居然变快了很多。
不过，我对于optimizer_search_depth=0并没有那么冒险，主要是怕影响查询逻辑。
我记得有一篇文章说，把这个参数设置为0后，一些复杂的查询就会变成顺序扫描，得不偿失。
建议先检查一下，不要一遇到就更换。

2 SQL语句分区 在将 IN 转换为多个 OR 时，我有一个非常具体的经验。
有一次我给客户调优的时候，一个IN位置有5 0个值，一直卡到早上。
后来改成OR链，结果居然出来了。
但要注意动态SQL中不要拆分IN参数，这样会更混乱。
例如，如果您使用FIND_IN_SET函数，MySQL优化器将根本无法识别它。
客户使用此函数来处理分隔字符串列表，但由优化器该指数被彻底拒绝。

3 取代加入 这是最漂亮的技巧，尤其是当 IN 条件来自相关表时。
我记得有一个支付系统。
查询未调整订单时，IN后面跟着上百个商户ID，扫描全表直至崩溃。
后来改写为JOIN，直接将商户表秒级链接到结果。
但请注意，JOIN 条件中的索引必须显式指定，例如 ON Table1 .id = Table2 .id USE INDEX(idx_id)。
有一种情况，因为没有添加，所以结果仍然是全表扫描。

4 临时表方法 我经常使用它，尤其是当参数固定时。
有CRM系统查询黑名单客户，很多手机号码固定为IN状态。
改写到临时表后，其实比缓存还要快。
但是，请注意，创建数据并将其插入临时表会产生开销。
例如，在一种情况下，向临时表插入1 0000条数据比直接IN条件慢3 0%。
建议仅当参数列表特别长时才使用此选项。

附加知识：MySQL 8 .0 中有一个新功能，您可以使用 EXPLAIN ANALYZE。
它比旧版本的 EXPLAIN 详细得多。
可以直接看到参数是扫描还是索引搜索。
一位客户信赖它，发现 IN 条件在参数扫描中得到了优化。

其实就是最基本的解决业务逻辑必须重建。
有一个案例，客户使用IN查询一个有上百个产品ID的订单，结果卡住了。
后来发现这些产品都是同一批促销的，最终改为使用Promotion ID关联表查询。
将复杂的查询直接转化为简单的JOIN，效果立竿见影。