问题一：粗粒度查询导致的问题及解决方案是什么？
粗粒度查询导致的问题及解决方案是什么？
参考回答：
粗粒度查询导致的问题是查询条件区分度不高，返回大量数据，即便加索引也难以显著提升性能。针对这个问题，一种解决方案是将数据对比逻辑转移到离线数据处理平台（如dataWork）上执行。通过离线任务先找出差异数据（这些数据量通常很小且区分度高），然后将差异数据回流到原数据库，最后通过差异数据更新原表，从而避免了对大表的直接操作，解决了慢SQL问题。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671764
问题二：OR条件在SQL中为什么会导致索引失效？
OR条件在SQL中为什么会导致索引失效？
参考回答：
在SQL查询中，当WHERE子句包含OR条件时，如果OR连接的每个条件都不能单独利用索引（尤其是当这些条件涉及不同的列时），则数据库优化器可能无法有效地使用索引来加速查询。这会导致全表扫描或索引合并操作，从而影响查询性能。例如，在提供的案例中，EXISTS子查询中的OR条件涉及多个列（biz_id、customer_id等），并且这些条件组合在一起可能无法高效利用索引，从而导致索引失效。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671765
问题三：如何优化包含OR条件的SQL查询？
如何优化包含OR条件的SQL查询？
参考回答：
优化包含OR条件的SQL查询可以考虑以下几种方法：
重写查询：尝试将查询重写为多个没有OR条件的查询，并使用UNION ALL或UNION合并结果。这样可以使每个查询都能单独利用索引。
使用索引合并：如果数据库支持索引合并优化（如MySQL的Index Merge Optimization），则可能不需要重写查询。但需要注意，索引合并不一定总是比单独索引更快。
评估查询条件：检查OR连接的每个条件，看是否有可以简化的地方，或者是否有一些条件实际上总是为真或为假，从而可以简化查询。
考虑业务逻辑：如果可能的话，改变业务逻辑以减少对这类查询的需求。例如，通过缓存结果或改变数据模型来减少查询的复杂性。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671766
问题四：为什么EXPLAIN结果显示XXX_white_list表的查询type为ALL，即扫描全表？
为什么EXPLAIN结果显示XXX_white_list表的查询type为ALL，即扫描全表？
参考回答：
尽管XXX_white_list表有将biz_id作为索引，但在EXPLAIN结果中显示type为ALL，这通常意味着索引没有被使用，导致进行了全表扫描。这可能是因为查询条件中使用了OR连接了多个条件，且其中一个条件（如customer_id LIKE CONCAT(t.biz_id, '@%')）未能有效利用索引。特别是当OR条件中的某个部分没有命中索引时，整个查询可能无法利用索引进行优化，从而导致索引失效，进行全表扫描。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671767
问题五：索引失效有哪些常见情况？
索引失效有哪些常见情况？
参考回答：
索引失效的常见情况包括：
OR查询左右有未命中索引的：如上述案例所示，OR连接的条件中如果有一个或多个条件未能命中索引，则整个查询可能无法利用索引。
复合索引不满足最左匹配原则：如果查询条件没有按照复合索引的顺序进行匹配，则索引可能无法被有效利用。
Like以%开头：当LIKE查询以%开头时，索引通常无法被使用，因为数据库无法确定搜索的起始点。
需要类型转换：如果查询条件涉及类型转换，且索引列的类型与查询条件不匹配，则索引可能失效。
where中索引列有运算：对索引列进行运算（如加减乘除）会导致索引失效。
where中索引列使用了函数：在索引列上使用函数也会使索引失效，因为数据库无法直接通过索引来快速定位数据。
如果MySQL觉得全表扫描更快时：在数据量较小或索引选择性不高的情况下，MySQL可能会选择全表扫描而不是使用索引。
关于本问题的更多回答可点击原文查看：
