Что приводит к уменьшению кардинальности MySQL?

В наших производственных системах MySQL у нас есть некоторые запросы, выполнение которых обычно занимает менее 2 секунд, но иногда они выполняются более минуты. Каждый раз, когда один из этих запросов выполняется долго, мы проверяем индексацию и обнаруживаем, что кардинальность упала в одном и том же поле VARCHAR(25). Мы запускаем MySQL как кластер мастера с несколькими подчиненными, и мы обнаружим, что количество элементов только на этой медленной системе уменьшилось, значение останется высоким на всех других серверах. Когда значение упадет, оно упадет примерно с 20-30 тысяч (высокое значение) до нескольких сотен. Выполнение команды ANALYZE TABLE исправляет кардинальность и доводит резервную копию до 20k-30k, и запрос снова выполняется быстро.

Я начал отслеживать количество элементов во всех таблицах, чтобы увидеть, как это значение меняется со временем. Я понимаю, что количество элементов будет увеличиваться по мере добавления новых данных, и я ожидаю, что оно будет уменьшаться по мере удаления записей, но в этой таблице очень редко удаляются записи, но значение будет увеличиваться и уменьшаться каждый раз, когда я смотрю на нее.

MySQL 5.5.8 InnoDB

ЦенОС 5.7

Любые идеи о том, что я должен искать? COUT(*) = 402259


person LinuxGuru    schedule 17.07.2014    source источник
comment
bugs.mysql.com/bug.php?id=44760 ?   -  person eggyal    schedule 18.07.2014
comment
Ошибка 44760 выглядит подозрительно похожей, если бы не тот факт, что я использую InnoDB, а не ndbcluster, и об ошибке сообщалось в версии 5.1, и я надеюсь, что 5.5, которую я использую, не будет такой старой ошибкой. Все еще очень интересно.   -  person LinuxGuru    schedule 18.07.2014
comment
Вы нашли причину этого???   -  person Sandeep B    schedule 02.12.2014
comment
Я не нашел причины падения кардинальности или обхода проблемы, которую это вызывает. Мы знаем, что когда наши таблицы имеют большое количество элементов, часто после того, как таблица была оптимизирована, наши запросы выполняются очень быстро. Мощность на столах с высокой активностью колеблется в течение дня. Если количество элементов падает более чем на 40%, производительность запросов к этой таблице снижается и иногда происходит блокировка. Любой запрос, который занимает больше 60 секунд, уничтожается. У нас также есть мониторинг Icinga на предмет падения количества элементов, чтобы сообщить нам об этом до того, как это произойдет. Пока нет решений.   -  person LinuxGuru    schedule 03.12.2014


Ответы (1)


Статистика таблиц InnoDB является приблизительной, а не точной. Итак, если вы хотите узнать точную кардинальность поля, вы можете запустить этот запрос:

SELECT COUNT(DISTINCT field_name) FROM table_name
person Jehad Keriaki    schedule 17.07.2014
comment
Все ведомые устройства имеют идентичные счетчики с ведущим 7657. Когда я использую SHOW INDEXES FROM table_name, я получаю число элементов 9305 на ведущем устройстве и 21189,11503,7742 и 6913 на ведомых устройствах. Все ведомые отстают от ведущего на ноль секунд. Числа оставались неизменными в течение нескольких минут, затем ведомое устройство с 21189 упало до 7742, в то время как все остальные ведомые устройства и мастер остались прежними. - person LinuxGuru; 18.07.2014
comment
Это возможно и вполне нормально. На самом деле сложно получить одинаковую статистику на разных серверах, даже если у них одинаковые данные. За этим стоит несколько факторов. Основным фактором является то, как InnoDB хранит данные и индексы. Он использовал B-Tree для индексов, откуда показывается кардинальность. Попробуйте проверить размер файлов на мастере и слейве, он не будет одинаковым. - person Jehad Keriaki; 18.07.2014