Какой подход более оптимизирован для сбора как общего количества записей, так и части результатов? [Дубликат]
Чтобы использовать методы и член объекта, вам сначала нужно создать этот объект. Если вы его не создали (переменная, которая должна содержать объект, не инициализируется), но вы пытаетесь использовать его методы или переменные, вы получите эту ошибку.
Иногда вы можете просто забыть инициализировать .
Отредактировано: new не может вернуть значение null, но исключение огня при ошибке. Давно это было на некоторых языках, но не больше. Спасибо @John Saunders за указание на это.
5 ответов
Это зависит. См. Сообщение в блоге MySQL Performance Blog на эту тему: http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/
Просто краткое изложение: Питер говорит, что это зависит от ваших индексов и других факторов. Многие комментарии к сообщению, похоже, говорят, что SQL_CALC_FOUND_ROWS почти всегда медленнее - иногда до 10 раз медленнее - чем выполнение двух запросов.
-
1– Sam Dufel 12 July 2012 в 00:59
-
2– svidgen 9 January 2013 в 22:56
-
3– dynamic 10 March 2013 в 16:21
-
4– qpaycm 20 July 2013 в 16:37
-
5– transilvlad 24 March 2014 в 19:16
При выборе «лучшего» подхода более важным соображением, чем скорость, может быть удобство и правильность вашего кода. Если это так, то SQL_CALC_FOUND_ROWS предпочтительнее, поскольку вам нужно поддерживать только один запрос. Использование одного запроса полностью исключает возможность тонкой разницы между основными и счетными запросами, что может привести к неточному COUNT.
-
1– mpen 28 April 2014 в 16:48
Удаление ненужного SQL, а затем COUNT(*) будет быстрее, чем SQL_CALC_FOUND_ROWS. Пример:
-
SELECT Person.Id, Person.Name, Job.Description, Card.Number -
FROM Person -
JOIN Job ON Job.Id = Person.Job_Id -
LEFT JOIN Card ON Card.Person_Id = Person.Id -
WHERE Job.Name = 'WEB Developer' -
ORDER BY Person.Name
Затем рассчитывать без ненужной части:
-
SELECT COUNT(*) -
FROM Person -
JOIN Job ON Job.Id = Person.Job_Id -
LEFT JOIN Card ON Card.Person_Id = Person.Id -
WHERE Job.Name = 'WEB Developer' -
ORDER BY Person.Name
Согласно следующей статье: https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/
Если у вас есть INDEX в вашем предложении where (если идентификатор проиндексирован в вашем случае), тогда лучше не использовать SQL_CALC_FOUND_ROWS и вместо этого использовать 2 запроса, но если у вас нет указатель на то, что вы помещаете в свое предложение where (id в вашем случае), а затем с использованием SQL_CALC_FOUND_ROWS более эффективно.
IMHO, причина, по которой 2 запроса
SELECT * FROM count_test WHERE b = 666 ORDER BY c LIMIT 5;
SELECT count(*) FROM count_test WHERE b = 666;
быстрее, чем использование SQL_CALC_FOUND_ROWS
SELECT SQL_CALC_FOUND_ROWS * FROM count_test WHERE b = 555 ORDER BY c LIMIT 5;
, следует рассматривать как частный случай.
Это в фактах зависит от избирательности предложения WHERE по сравнению с селективностью неявного, эквивалентного ORDER + LIMIT.
Как сказал Arvids в комментарии ( http: //www.mysqlperformanceblog .com / 2007/08/28 / to-sql_calc_found_rows-or-not-to-sql_calc_found_rows / # comment-1174394 ), тот факт, что EXPLAIN использует или нет временную таблицу, должен быть хорошей базой для того, чтобы узнать, будет ли SCFR быстрее или нет.
Но, как я добавил ( http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not- to-sql_calc_found_rows / # comment-8166482 ), результат действительно действительно зависит от случая. Для конкретного paginator вы можете прийти к выводу, что «для 3-х первых страниц используйте 2 запроса; для следующих страниц используйте SCFR "!