Добавление redudant условия объединения в Oracle приводит к другому плану
Для pip
pip install pymysql
Для pip3 вы должны использовать
python3 -m pip install PyMySQL
Затем отредактируйте файл init.py в исходной директории вашего проекта (так же, как settings.py). Добавить:
import pymysql
pymysql.install_as_MySQLdb()
4 ответа
What you've got is two issues.
Firstly, with the original SQL, the optimizer makes an estimate about the number of rows in A with rows matching the ID in B which also have a matching row in C. The estimate is inaccurate, and the wrong plan is chosen.
Now, you add the redundant condition. Oracle assumes no conditions are truly redundant (as, if they were, an intelligent developer wouldn't include them). It also assumes that each condition is independent of the others. For example, a select where hair = 'bald' may get 10% of a table, a select where gender = 'F' may get 50%. Oracle would assume that a select where hair = 'bald' and gender = 'F' would give 5% (whereas in reality baldness is mostly limited to men).
By adding the 'redundant' predicate, Oracle will over-estimate the numbers or rows to be excluded and will choose the plan accordingly.
If, with the redundant predicate, Oracle is choosing a better plan, it suggests that the estimates for the original query over-estimated the number of rows matching. The redundant predicate is countering that with an under-estimate. And in this case, two wrongs are making a right.
It's not a solution I'd recommend, but if it works.....
PS. I'm assuming data types of all the IDs are consistent. If B.ID and C.ID are date and A.ID was character, or vice versa, then it is possible to have some rows where A.ID = B.ID and A.ID = C.ID but B.ID != C.ID, because implicit conversion may lose timestamps.
Интересно.
Похоже, что Oracle может вывести это транзитивное равенство только при некоторых обстоятельствах: они называют это Transitive Closure , и вы сможете извлечь из этого выгоду, когда включена перезапись запроса.
Но на всякий случай лучше сформулируйте повторяющийся предикат самостоятельно.
Оптимизатор Oracle не делает транзитивных предположений о равенстве. Хотя мы понимаем, что если A = B и A = C, то B = C, Oracle не предполагает наличия связи между B и C, если она не указана явно в предложении WHERE или условиях JOIN.
I ' m при условии, что у вас есть другие ограничения для A, B и / или C (в отличие от простого выбора всего содержимого таблиц - иначе ваш ввод-вывод не был бы таким низким, если бы ваши таблицы не были крошечными, в этот момент оптимизация несколько спорный вопрос). Так что на A, B и C действительно больше ограничений, чем указано вами. Оптимизатор Oracle просмотрит все таблицы в предложении FROM, перечислит ограничения против них в предложении WHERE, а затем определит избирательность ограничений на основе индексов для этих таблиц. Затем он будет проходить через различные перестановки планов атаки и определять, какие из них дают наибольшие надежды (это значения мощности, которые вы видите в планах). Без условия B = C он исключает планы, которые начинаются с B и переходят к C (или наоборот), и это могут быть наилучшие возможные планы.
Эти два запроса мне совершенно не кажутся одинаковыми.
Опять же, я не оптимизатор Oracle.
Поскольку и B, и C имеют внешние ключи A, когда вы это сделали
INNER JOIN B
ON B.id = A.id
, результирующий набор результатов (скажем, несколько раз быстрее), на котором вы присоединяетесь к таблице C во второй запрос меньше, как вы видели в результатах своего плана выполнения, чем когда вы присоединяете таблицу C исключительно к таблице A, как в вашем первом запросе.
Итак, вы оптимизировали ситуацию во втором запрос путем соединения таблицы C с меньшим набором данных, который является пересечением A и B, и меньшим набором данных, который является пересечением A и C.