|
| |
|
|
| |
для: Gemorroj
(11.11.2008 в 21:58)
| | | Ну а что тут можно сказать кроме как...
http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_count
COUNT(expr)
Returns a count of the number of non-NULL values of expr in the rows retrieved by a SELECT statement. The result is a BIGINT value.
COUNT() returns 0 if there were no matching rows.
mysql> SELECT student.student_name,COUNT(*)
-> FROM student,course
-> WHERE student.student_id=course.student_id
-> GROUP BY student_name;
COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.
COUNT(*) is optimized to return very quickly if the SELECT retrieves from one table, no other columns are retrieved, and there is no WHERE clause. For example:
mysql> SELECT COUNT(*) FROM student;
This optimization applies only to MyISAM tables only, because an exact row count is stored for this storage engine and can be accessed very quickly. For transactional storage engines such as InnoDB and BDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.
#
поэтому время исполнения 1-го запроса несколько удивляет... | |
| |
|
|
| |
|
|
| |
для: Trianon
(11.11.2008 в 21:12)
| | | id да, PRIMARY KEY
таблица MyISAM
попробую
Завтра постараюсь потестить более подробно. Эта конкретная БД меня не интересует. Меня интересует вообще поведение данных функций. | |
| |
|
|
| |
|
|
| |
для: Gemorroj
(11.11.2008 в 20:40)
| | | 1. id описан как PRIMARY KEY?
2. таблица MyISAM? и если да, то
3. OPTIMIZE TABLE делать пробовали?
разница между последними двумя наверняка тоже из-за кеширования результатов самим сервером. | |
| |
|
|
| |
|
|
| |
для: Trianon
(11.11.2008 в 17:28)
| | | сейчас попробовал на реальной БД поэксперементировать. В таблице около миллиона записей.
SELECT COUNT(*) FROM `feed_item`; // 400-700 ms
SELECT COUNT(*) FROM `feed_item` LIMIT 1; // 400-700 ms
SELECT COUNT(*) FROM `feed_item` WHERE `id`>1; // 500-900 ms
SELECT COUNT(*) FROM `feed_item` WHERE `id`>1 LIMIT 1; // первый запрос 8 секунд, последующие - 400-800 миллисек
|
P.S. ошибся кажется, Без LIMIT тоже первый запрос долго считает | |
| |
|
|
| |
|
|
| |
для: cheops
(11.11.2008 в 17:19)
| | | >Однако, если появляется конструкция WHERE, требуется скан таблицы и получение результата может быть достаточно трудоемкой задачей, особенно, если объем таблицы составляет десятки мегабайт или выше.
и при этом LIMIT 1 может (без GROUP BY) как-то влиять ?
[Нет, я не советую его ставить или наоборот срезать] | |
| |
|
|
| |
|
|
| |
для: cheops
(11.11.2008 в 17:19)
| | | Спасибо, теперь понятно. А если имеется следующий запрос
SELECT COUNT(*) FROM `table` WHERE `id`>1;
|
Но, на `id` стоит индекс, будет ли происходить сканирование всей таблицы? | |
| |
|
|
| |
|
|
| |
для: Gemorroj
(11.11.2008 в 15:37)
| | | Вообще-то именно с COUNT(*) такого не должно быть - результат заведомо возвращается единичный и оптимизатор об этом "знает". Именно в том виде в котором вы указали, COUNT(*) очень "легкая" функция, так как скана таблицы не происходит, а число записей берется из мета-данных. Однако, если появляется конструкция WHERE, требуется скан таблицы и получение результата может быть достаточно трудоемкой задачей, особенно, если объем таблицы составляет десятки мегабайт или выше. | |
| |
|
|
| |
|
|
| | здравствуйте.
допустим есть следующий SQL запрос
SELECT COUNT(*) FROM `table`;
|
НО, часто рекомендуют использовать для оптимизации оператор LIMIT в запросах, при модификации запроса следующим образом
SELECT COUNT(*) FROM `table` LIMIT 1;
|
время выполнения значительно возрастает. Почему так?
И еще, на сколько функция COUNT тяжелая? Как сильно она зависит от количества записей в БД? | |
| |
|
|
|
