2013-05-23 1 views
1

Я заметил проблему с GROUP BY в запросе, который я сейчас пытаюсь отлаживать. У меня есть таблица БД со следующей структурой (уменьшено с фактической реальной жизни):MySQL GROUP BY работает неправильно с символами умляута?

CREATE TABLE IF NOT EXISTS `product_variants` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `product_id` int(11) unsigned NOT NULL DEFAULT '0', 
    `pid_merchant` varchar(50) NOT NULL, 
    `checksum` char(32) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `checksum` (`checksum`), 
    KEY `product_id` (`product_id`), 
) ENGINE=InnoDB DEFAULT CHARSET=latin1; 

В этой таблице, у меня есть следующие 2 строки (среди многих других миллионов):

INSERT INTO `product_variants` (`id`, `product_id`, `pid_merchant`, `checksum`) VALUES 
(525555236, 628702710, 'ARTüöäß111', 'af5334b1193bf171580c70813ac83327'), 
(525555241, 628702710, 'ARTüöäß222', 'cfe50fd9c3ca29fd957b839892313f82'); 

Запрос Я в настоящее время отладки пытается найти дубликаты записей в этой таблице основаны на pid_merchant, в очень простой вопрос:

SELECT count(*), pv.* FROM product_variants pv WHERE pv.pid_merchant != '' GROUP BY pv.pid_merchant HAVING count(*) > 1 

Моя проблема заключается в том, что оба эти результаты совпадают, даже если фактические значения pid_merchant отличаются друг от друга: один заканчивается на 111, другой - в 222. Кто-нибудь знает, как подойти к этой проблеме? Я уже пробовал группировать MD5() и HEX(), меняя порядок сортировки на latin1_german2_ci, заставляя преобразовать двоичные или utf8 и многие другие - почти все, о чем я мог думать.

Еще одна странная вещь заключается в том, что она сбивает с толку значения Y и Ü (капитал U с умлаут), тогда как группировка (например, ABC-Y и ABC-Ü считаются идентичными при группировке).

Сервер работает под управлением MySQL 5.5 на Ubuntu x64:

mysqld Ver 5.5.29-0ubuntu0.12.04.2-log for debian-linux-gnu on x86_64 ((Ubuntu)) 
+0

Вы показываете нам две строки, где 'pid_merchant' явно отличается, и вы пытаетесь найти дубликаты? – mogul

+0

«pid_merchant» явно отличается, однако они оба соответствуют GROUP BY, это и есть точка. Однако переход на синтаксис ANSI (в соответствии с @gbn) фиксировал группу по выпуску. – Elis

ответ

1

Это не умляут (или акцентами вообще) проблема

Это то, как MySQL оценивает GROUP BY: это нестандартное и случайные , Стандарт SQL:

SELECT count(*), pv.product_id, pv.pid_merchant 
FROM product_variants pv 
WHERE pv.pid_merchant != '' 
GROUP BY pv.product_id, pv.pid_merchant 
HAVING count(*) > 1 

Все неагрегированные столбцы должны отображаться в GROUP BY.

MySQL имеет «полезные» расширения MySQL, которые устраняют это строгое требование. Это часто случается

+0

Благодарим вас за быстрый ответ, слишком легко изучить вредные привычки и упасть с ANSI. Ура! – Elis

+0

Вы можете заставить MySQL вести себя лучше с режимом ONLY_FULL_GROUP_BY. См. Http://dev.mysql.com/doc/refman/5.5/en/group-by-extensions.html для более – gbn

+0

Да, я наткнулся на эту информацию во время моих исследований, но, к сожалению, это не вариант для этого с которым я работаю. Еще раз спасибо за усилия! – Elis