От време на време, чрез четене на някой друг код, виждам, че някои фирми предлагат различни варианти във функцията COUNT (), за да се получи kolichetsvo линии.
Например: брой (*), брой (ID) (където е номер - е основният ключ). брои (0).
Възниква въпросът: "Какъв брой () е правилно? Що за псевдо-брой-ите? "
В основата на "правилността" е взел със скоростта на заявката.
Пусни 3 поискване:

Всички три получи изпълнение 0,03 - 0,04 сек. и, странно, един и същ резултат - броят 47915774.

Намерено в документацията е:

Прави впечатление, че при липсата на други тестове, които направих за MyISAM маса.

В действителност няма нищо чудно тук, защото ние отиде по-далеч.
Налице е в моя индекс плоча поле
`C_time` час и дата NOT NULL подразбиране" 0000-00-00 00:00:00 "

3 изпълняват една и съща заявка, но с ограничението на c_time:

В първите два случая, получи заявка времето за изпълнение на 2.84 - 3.15 секунди, а трети 27.46 - (.) 28,34 сек.

Обръщам се към вътрешната светая светих на MySQL-гуру - ОБЯСНЕТЕ искане и да признаем, че в последния случай в областта Екстра "светлини", за да "Използване където", а в първите две заявки за допълнителни предавания "Използване където; Използване на индекс".

На тази трагична бележка, моите тестове са минало.
По-интересното vzgyanut на подобни резултати в заявките, в които КЪДЕ извършва от не-ключово поле, а не на MyISAM маса.

Послепис Между другото, той, по някаква причина непознат за мен, използвайте брой (*).

19 коментара към "правилния брой () в MySQL"

Имайте предвид, че ако използвате индекс в подготовката на редица линия на разследване
SELECT COUNT ( `id`) като CNT FROM` users` УПОТРЕБА INDEX (as_id) когато` siteuser` = 1. И `active` = 1 ':
времето за изпълнение е по-малко от броя (*) и броят (0), т.е. използване на индекси е по-добре да се използва "идентифицираща"
I as_id Idex е сноп ID колони, siteuser и активно.

Idex as_id е свързан ID колона, siteuser и активно.

И това, което идентификатор на Сува?
Подозирам, че имате номер на първичен ключ, който в действителност е индексът.

Да, но пробата - това е не само кметове, но също така и активно siteuser

но пробата - това е не само кметове, но също така и активно siteuser

И ако сте готови за вземане на проби при всички комбинации на 5 полета - ще бъде 120 индекси всички полета, за да създадете комбинации?

Какво пречи на MySQL индекс използване 2?
Първият - първичен ключ (номер), втория ключ (siteuser, Active)
Или дори 3: основен ключ (номер), на втория ключ (siteuser), ключ (активна)?

Sense да добавите номер към композитен индекс просто не разполага с: ако не е зададен номер, а след това ще използва MySQL първичен ключ и други индекси дори няма да погледна.
Ако не е посочен идентификационен номер на заявка след това си съставен индекс също ще бъде като мъртви лапи, тъй като индекс двойка (siteuser, активна) не, има само три от са (ID, siteuser, активна).

Добър въпрос, който го възпрепятства, тъй като той не ги използвате.
И като съставен индекс и да го използвате като се посочва промените, които са направили процент искане от 8 секунди до 0.7 секунди.
Налице е храна за мозъка.

Защо не се използва MySQL индекс - отделен въпрос, а функцията COUNT не се прилага.
Това е напълно възможно, че прогнозният брой редове, в резултатът е повече от 15-20% от общия брой - в този случай, оптимизатор мисли, че е по-добре да прекарат fullscan маса можете да използвате индекси. Но за съжаление понякога той не е наред.

Послепис Надявам се, че въпросът е защо не трябва да добавите основен ключ в Съставният индекс, не си струва?

Благодаря, много полезен пост.
Сложих на здравия разум на вътрешния оптимизатор MySQL.
не много в шок, на живо и да се учат. - |

ОБЯСНЕТЕ SELECT брой SQL_NO_CACHE (0)
От 'news`
КЪДЕТО `type` = 2

идентификатор | select_type | маса | тип | possible_keys | ключ | key_len | Код | редове | extrara
1 | SIMPLE | новини | Код | тип | тип | 4 | Конст | 8623 | Използване където; Използване на индекс

и когато броят (ID) са само с помощта на които големи трупи.

Колко линии на всички на масата?
Колко от тях са обхванати от условията `type` = 2?
Какъв тип тип поле?
Според него, построен индекс?

Има подозрения, че номерът (0) оптимизатор реши, че е по-евтино да изпълнява всички маси fullscan вместо да използвате индекс (такива неща се случват, когато очакваният брой на записите надхвърли 20-25% от общия брой).
Защо в този случай, това не се случи с броенето (ID) - Трудно е да се каже.