Вижте Как MySQL използва индекси .
Също така проверете дали MySQL все още извършва пълно сканиране на таблица след като добавите още около 2000 реда към вашите user_metrics маса. В малките таблици достъпът по индекс всъщност е по-скъп (по отношение на I/O) от сканирането на таблица и оптимизаторът на MySQL може да вземе това предвид.
Противно на предишната ми публикация , се оказва, че MySQL също използва оптимизатор, базиран на разходите
, което е много добра новина - т.е. при условие, че стартирате своя ANALYZE поне веднъж, когато смятате, че обемът на данните във вашата база данни е представителен за бъдеща ежедневна употреба.
Когато работите с базирани на разходи оптимизатори (Oracle, Postgres и т.н.), трябва периодично да изпълнявате ANALYZE
на различните ви маси, тъй като размерът им се увеличава с повече от 10-15%. (Postgres ще направи това автоматично вместо вас, по подразбиране, докато други RDBMS ще оставят тази отговорност на DBA, т.е. на вас.) Чрез статистически анализ, ANALYZE ще помогне на оптимизатора да получи по-добра представа за това колко I/O (и други свързани ресурси, като CPU, необходими например за сортиране) ще бъдат включени при избора между различни планове за изпълнение на кандидатите. Неуспешно изпълнение на ANALYZE може да доведе до много лоши, понякога катастрофални решения за планиране (напр. заявки за милисекунди отнемат, понякога, часове поради лоши вложени цикли на JOIN с.)
Ако производителността все още е незадоволителна след изпълнение на ANALYZE , тогава обикновено ще можете да заобиколите проблема, като използвате съвети, напр. FORCE INDEX , докато в други случаи може да сте се натъкнали на грешка в MySQL (напр. тази по-стара , което би могло да ви ухапе, ако използвате nested_set на Rails ).
Сега, тъй като сте в приложение Rails , ще бъде тромаво (и ще попречи на целта на ActiveRecord ), за да издадете вашите персонализирани заявки със съвети, вместо да продължите да използвате ActiveRecord -генерирани.
Споменах това в нашето приложение Rails всички SELECT заявките паднаха под 100 ms след преминаване към Postgres, докато някои от сложните присъединявания, генерирани от ActiveRecord понякога отнема до 15 секунди или повече с MySQL 5.1 поради вложени цикли със сканиране на вътрешна таблица, дори когато са налични индекси. Никой оптимизатор не е перфектен и трябва да сте наясно с опциите. Други потенциални проблеми с производителността, за които трябва да сте наясно, освен оптимизирането на плана на заявките, се заключват. Това обаче е извън обхвата на вашия проблем.
