ошибки в db.log

Добрый день!

Слишком часто стали появляться ошибки в логах db.log подобного вида:

Query Error 1267: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' Query: SELECT * FROM shop_search_word WHERE name LIKE '?????????'

Подскажите пожалуйста, что с этим делать? Установлены все последние версии.

8 ответов

  • 1

    Добрый день!

    С первого взгляда похоже на......

    1. Включить режим отладки ("Настройки")
    2. Посмотреть "Таблицы и поля без поддержки эмодзи" ("Настройки" - "Базы данных")
    3. Что в "Кодировка соединения"?
    4. "Перейти к добавлению поддержки эмодзи"
    5. "Сменить кодировку"
    6. "Запустить"
    • +1

      Спасибо большое, попробую! Просто странно, не могут же люди в поиск эмодзи вводить..

      • +1

        во-первых в строку ввода можно что-нибудь скопипастить. Во-вторых, если windows, сочетание кнопок на клавиатуре Win+(точка) никто не отменял

      • +3
        replicant replicant 22 января 2023 21:51 #

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

        Даже точечная правка сравнения этой таблицы целиком и/или столбца name в utf8mb4_general_ci спасет от такой ошибки вне зависимости как такое туда попадает.


        Оптимально конечно ещё бы надо проверить нет ли у вас в названиях и описаниях товаров эмодзи. Это и может быть источником такой записи в логах.

        • +1

          Благодарю! Включение эмодзи на всю таблицу не получилось, сайт почему-то завис при включении режима отладки, быстро ее отключила, сейчас попробую действительно только поле с названием вручную изменить.

          И это оказались запросы ботов яндекса, вера в людей осталась ))

    • -2

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

      В этом то вся и проблема, люди все обновили, видят пункт "Включить поддержку Эмодзи", нажимают, он запускается, а потом заканчивается с ошибкой, и часть таблиц в Базе данных становятся в кодировке UTF8 а часть в новой UTF8mb4. Скрипт при ошибке за собой не прибирает, т.е. не возвращает в исходное положение таблицы, и по сему - получается при совместном использовании таблиц в разных кодировках, к примеру JOIN - всеми любимый, когда происходит объединение таблиц в разных сопоставлениях - появляется ошибка в БД.

      Лучше обратитесь, напрямую ко мне - исправлю результат быстро и оптимизирую работу БД.

  • -3

    Перевод вашей ошибки: Неверное объединение сопоставлений (разные кодировки), пытаетесь сопоставить UTF8mb4 и UTF8

    Да, профессионализм ответов - зашкаливает, а ничего что он пытается объединить таблицы разных кодировок. О чем я везде и писал, все таблицы Шопскрипта, храните в одинаковой кодировке, и настройка Базы Данных (сопоставление), аналогично должна быть в той же кодировке. Соответственно:

    1. Привести все таблицы в одинаковую кодировку, в т.ч. желательно и столбцы в ней.
    2. Привести настройку ответа базы данных (сопоставления) в такую же кодировку, это ускорит выдачу результата, т.к. Базе данных не надо будет пересчитывать результат.
    3. Выбор кодировки, если Эмоджи не нужен, (эмоции в сообщениях комментариях и т.д.) - то везде выставить UTF8_general_ci, это уменьшит размер базы на 25-30%.
    4. Если все же Эмоджи нужен, смотри пункт выше, то везде выставить UTF8mb4_general_ci
    5. При не возможности осуществить полный переход на Utf8mb4, обрезать ключевые поля с 255 символов, до 191, т.к. это уже позволит перевести её в Utf8mb4, но лучше все вернуть в UTF8!!!

    В InnoDB движке (вплоть до версии MySQL 5.5.14) существуют следующие ограничения на длину поля с уникальным ключем:
    — для кодировки utf8 и типа поля TEXT и VARCHAR максимальная длина поля 255 байт;
    — для кодировки utf8mb4 и типа поля TEXT и VARCHAR максимальная длина поля 191 байт;
    
    В кодировке utf8 (utf8mb3) один символ занимает 3 байта, то есть 3 * 255 получаем наши 767 байт лимита.
    В кодировке utf8mb4 один символ занимает 4 байта, то есть 4 * 191 получаем наши 767 байт лимита.

    P.s. Как можно перекодировать таблицы быстро в UTF8

    ALTER TABLE `имя_таблицы` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

    И соответственно в UTF8mb4, так

    ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите