。

本文将分享如何通过查询改写的2种方式进行优化…这篇博客涉及两个点一个是

“OR

------------------------------------------------------------------------------------

Query

------------------------------------------------------------------------------------

|ID|OPERATOR

-----------------------------------------------

|TABLE

-------------------------------------

output([t1.c1],

filter_before_indexback[false],

range_key([t1.c1]),

------------------------------------------------------------------------------------

rows

如果大家一时反应不过来为何无法利用索引那这里就再多解释几句因为在一个

table

上的索引也会出现类似的情况。

所以无论怎么建索引怎么用索引这次全表扫总归是逃不掉的。

基础知识

函数大家可以简单的理解成是一个类似于逻辑非的操作。

这个改写一般被称为

ExpansionOR

的改写。

这样查询就会被拆分为两个部分分别利用两个索引在某些场景下可能可以提升查询性能。

explain

-----------------------------------------------------------------------------------------------

Query

-----------------------------------------------------------------------------------------------

|ID|OPERATOR

----------------------------------------------------

|UNION

-------------------------------------

output([UNION([1])],

filter_before_indexback[false],

range_key([t1.c2],

-----------------------------------------------------------------------------------------------

rows

“在某些场景下可能可以提升查询性能”原因是优化器的改写算法分为两类

第一类叫基于规则的改写这类改写总会有正面的效果例如消除恒真、恒假条件。

第二类叫基于代价的改写特点是某些场景下改写后能生成更好的执行计划另一些场景下则不能。

是否可以触发这类改写优化器会根据实际的数据分布、是否有合适的索引等因素来进行判断。

基于代价的算法在完成改写后需要

“询问”

是否能够生成执行代价更小的计划”如果代价的确降低了这次改写才会被触发。

Expansion就属于第二类

两边都有索引并且索引的过滤性不错的情况下才能够达到优化的目的。

Q1:

上的索引。

如果这两个过滤条件有强的过滤性那么索引扫描可以大大减少读取数据的开销。

此时触发

Expansion

子句它需要进行两次全表扫描。

因此改写后的执行代价会上升。

在这种情况下不应该触发

综上所述在没有及时收集统计信息时即优化器不能准备计算代价时可以根据实际情况两边是否都有索引以及索引过滤性通过

Hint