解析MySQL DELETE语句不走索引：原因及优化策略

什么SQL语句不走索引啊?能举几个例子么?

如果字段在未建立索引的地方使用，则它们不会被索引。

SQL这样delete居然不走索引

背景描述了大规模数据清理任务中出现的挑战。
使用阿里云Polardb数据库进行多线程并发处理，出现“Lockwaittimeoutexceeded;tryrestartingtransaction”错误，日志显示获取锁失败。
但是，使用RC隔离级别必须防止死锁。
通过分析，发现SQL执行计划有问题。
通过简化表结构，使用SELECT而不是DELETE来获取执行计划，我发现DELETE操作实际上是进行了全表扫描，而不是使用索引。
这与使用索引进行SELECT操作形成鲜明对比，表明问题的症结在于DELETE语句的特殊处理。
进一步分析指出，DELETE语句出现的问题与SQL内部处理逻辑有关，即MySQL优化器在处理包含子查询的DELETE语句时可能会选择不同的执行策略，从而导致。
全表扫描和未使用的索引。
这与MySQL的优化器选择问题有关，它改变了优化器的行为，特别是当某些优化开关关闭时。
打开优化器开关后，可以看到优化器将IN子查询转化为EXISTS逻辑，实现索引利用。
当此开关关闭时，优化器会选择全表扫描，这会降低性能。
DELETE语句中的相同逻辑问题会导致全表扫描和锁等待超时问题。
我们讨论了MySQL的SEMIJION技术，这是一种优化IN/EXISTS子查询的方法，可以提高查询效率。
但由于技术限制和MySQL的bug，SEMIJION优化并未应用于DELETE语句。
这限制了DELETE语句使用索引的可能性。
总结指出，优化器的选择策略、SQL内部处理逻辑以及MySQL的技术限制导致DELETE语句无法利用索引。
在实际场景中，可以避免使用子查询，而使用JOIN方法来解决这个问题，提高查询效率。