#neo4j
Вопрос:
Это происходит не всегда, но с одной и той же базой данных (и, возможно, с другим поиском узлов) мое ОБЪЯСНЕНИЕ продолжает показывать тысячи строк там, где я ожидал бы только одну. Я что-то упускаю?
напр.:
EXPLAIN MATCH (node:Label)
WHERE node.UniqueID=1
WITH DISTINCT node
RETURN node
Существует 11000 записей с этой меткой, и это показывает правильное начало.
Но затем фильтр сужается до 1105, что не имеет смысла.
И РАЗНИЦА сужается до 1105, что также не имеет смысла.
Когда я запускаю запрос, я просто получаю свой единственный уникальный узел. Когда я запускаю объяснение, в результате отображается 1105 строк. Почему такое несоответствие? Я заметил, когда это происходит, что все ниже по течению останавливается, поэтому я думаю, что запрос выполняет больше работы, чем нужно, но я не уверен, почему. Я был бы очень признателен за указания на ресурс, который лучше объясняет это.
ТИА!!
Ответ №1:
Это оценочные строки, рассчитанные до выполнения запроса, они не представляют фактические строки из выполнения (для этого можно использовать ПРОФИЛЬ).
Оценочные строки именно таковы, оцениваются с учетом того, что известно из графика с помощью статистики и данных из хранилища подсчетов.
Поскольку они рассчитываются перед выполнением, планировщик понятия не имеет о специфике свойства, используемого для поиска.
Если у вас действительно есть уникальный идентификатор, то вы должны создать для него уникальное ограничение, чтобы планировщик смог это понять и дать более полезную оценку. Он также сможет использовать индекс (который поставляется с уникальным ограничением) для повышения скорости поиска.
Кроме того, при таком изменении вам больше не нужно будет использовать DISTINCT, так как уникальный поиск по индексу гарантирует это.
Комментарии:
1. Спасибо, это все объясняет. Я не понял, что ОБЪЯСНИТЬ-это оценка (в отличие от ПРОФИЛЯ). Вы правы — профиль возвращает только 1 строку.
2. Есть ли у ОБЪЯСНЕНИЯ трудности с оценкой процедур apoc? Я использую apoc.refactor.mergeNodes для объединения двух уникальных узлов, и из этих двух уникальных узлов я получаю 10 000 оценочных строк вместо 1. (Запрос завершается сбоем, поэтому я не могу его профилировать).
3. Планировщик не сможет получить какие-либо соответствующие данные из вызова процедуры, поэтому не полагайтесь на точность или полезность обращений к базе данных или оценочных строк от операторов вызова процедуры.
4. Большой вывод здесь заключается в том, что вам не нужно сильно беспокоиться о предполагаемых строках. Планировщик часто делает приблизительные оценки, экстраполированные из того, что он знает, но оценочные строки действительно полезны только для определения того, как планировать запрос, а не для настройки запроса. Напротив, фактические строки из ПРОФИЛЯ очень полезны. Если у вас возникли проблемы с запросом, либо создайте другой вопрос, либо задайте его на наших форумах сообщества.