Почему не сходится число уникальных записей в mysql?

Question

[Vladimir Zharinov]

В phpmyadmin вижу следующую картину в индексах таблицы (скрин)


При этом, уникальных элементов никак не может быть равное количество.
У поля code тип varchar(50) utf8_unicode_ci
location_id тип int(10)

В чём может быть дело?

Answer 1

[neol]

Это вывод результата выполнения запроса SHOW INDEXES FROM table и для InnoDB он показывает чёрт знает что (гугл выдаст пачку багов для разных версий MySQL). Вроде проблему решили в MySQL 5.7

phpmyadmin в данном случае просто выводит то, что ему отдаёт MySQL.

Comments

[Vladimir Zharinov]

И правда, в MySQL 5.7 всё показывается корректно!

Answer 2

[Евгений Вольф]

Судя по Вашей картинке, а так же вопросу, подозреваю, что дело может быть в PHPMyAdmin'е, либо в тех, кто его локализовывал (переводил на русский).

Мой Вам совет - выкиньте PHPMyAdmin, он отлично годится, что бы сохранять дамы небольших БД или загружать их обратно в условиях хостинга. Для MySQL есть масса отличных программ:
1. HeidiSQL
2. MySQL Workbench
3. Navicat
и т.д.

возьмите любую из них и забудьте о подобных проблемах

P.S. Подозреваю, что в той колонке (с заголовком "Кол-во уникальных элементов") указывается на самом деле не кол-во уникальных элементов а приблизительное кол-во записей в таблице, возможно результат генерирует какая-то из этих команд: эта или эта. Если Вы хотите в точности получить ответ на этот вопрос (что там за цифра и откуда она) - нужно включить логирование в MySQL всех запросов и посмотреть, какие запросы выполняются во время открытия конкретно этой страницы... найти нужный и т.д. Но я бы не стал тратить время на такую ерунду.

Comments

[Егор]

А если удаленный доступ к базе закрыт, какой из этих инструментов взять которые советуете ?

[Евгений Вольф]

Егор, если удаленный доступ к базе закрыт, инструменты всё те же, подход другой. Некоторые варианты:
а) Совсем дешевый хостинг (за 0.5-1$) на котором "нет ничего", как следствие - проект тоже довольно мелкий -- выгружаем базу к себе, делаем все необходимые манипуляции, загружаем базу обратно, либо - банально меняем хостинг на более адекватный, что бы не заниматься чем-то вроде "сначала сами себе создаём проблемы, а потом сами же их и решаем".
б) Хостинг чуть подороже (или не "подороже", а просто "получше"), на котором есть SSH и/или возможность открыть доступ к базе удаленно - либо пробрасываем SSH-туннель к базе и работаем с ней, либо открываем доступ к БД удаленно (с учётом мер безопасности, разумеется)

P.S. Для любого мало мальски "нормального" проекта, проблема уровня "у меня нет удаленного доступа к БД" не возникает априори. Это проблема проектов уровня "Блог про мою собаку на Wordpress" или проблема не правильного построения механизмов работы приложения/проекта ("сначала оплатил хостинг, а потом узнал, что там нет удаленного доступа к БД и/или SSH"). Даже на VPS за 1.5-2$/мес (что более чем сопоставимо с ценой большинства даже самых дешевых хостингов) подобной проблемы не может возникнуть по определению.

[Егор]

Варианты а) и б) отличные.
А если это заказчик, и хостинг с phpmyadmin выбирал он, что в таком случае делать ?

[Евгений Вольф]

Егор, вариантов в целом, как обычно несколько, например:
1. Как я уже писал выше - процесс разработки - это процесс разработки и к хостингу он никак не относится. Соответственно, разрабатывать проекты подобного уровня, с вероятностью примерно 127% - нужно локально. К проектам "подобного уровня" относятся примерно все проекты с пометкой "заказчик выбрал дерьмовый хостинг" или вообще проекты которые связаны со словом "хостинг". Думаю, не нужно объяснять, что практически любой проект, который предполагает хоть какой-то намек на нагрузку, на "хостинге" такого уровня, который "выбрал заказчик" - работать если и будет, то не долго, т.к. сайт "попросят", что бы остальным не мешал. По этому, слово "хостинг" в подавляющем большинстве случаев, связано с другим словом - "CMS".И каких-то глобальных проблем с тем, что выгружать заранее подготовленную базу (или загружать её обратно) через phpMyAdmin - я лично не вижу.
2. Одна из задач того, кто общается с заказчиком (в зависимости от масштабов разработки это может быть от самого разработчика [лично], до специально обученных людей) состоит в том, что бы убедить заказчика сделать правильный выбор, включая правильный выбор хостинга. Или, обозначить заказчику требования к тому же хостингу заранее.

К чему я это всё... Проблемы масштаба "заказчик нищеброд, и принципиально пользуется хостингом за 1$/мес." - свойственная для проектов с соотв. стоимостью, и разработчиков которые подобной стоимости под стать. Ни одна уважающая себя компания (или даже ещё не компания) не будет заниматься такой ерундой, как разглагольствовать на тему уровня "давайте хостинг за 1$/мес., поменяем на хостинг за 2$/мес.", так как масштаб цен не тот. И обсуждения подобного уровня вопросов (трата времени на вопросы подобного уровня) - равносильно тому, что выпрашивать в скидку в 100руб., в автосалоне, при покупке машины за пару млн. Если заказчик будет упираться в то, что он потратил на хостинг целых 12$ (за год), а нужно хостинг за 24$ (на котором "всё работает") - я подарю ему такой хостинг сам, т.к. это гораздо дешевле, чем рассусоливать вопросы подобного уровня, т.к. банально час работы 1-го разработчика стоит дороже чем цена всего вопроса.

[Егор]

Евгений Вольф, ваши мысли хороши. Если оторваны от контекста.
А человек задал конкретный вопрос: "Почему не сходится число уникальных записей".
Вы же предлагаете альтернативы, которые, судя по всему, могут не работать в определенных ситуациях. Зачем их предлагать?
А рассуждения какой должен быть хостинг, как нужно общаться с заказчиками отношения к вопросу не имеют.

[Евгений Вольф]

Егор, ну... мои рассуждения про хостинг, которые не имеют отношения к теме - начались с Вашего вопроса (про доступы к базе и т.д.), который точно так же не имеет ничего общего с изначальным вопросом.

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