логин: 
Другие записи за это число:
2011/07/22_1 - Определение IP и MAC-адреса в JavaScript и прочие шутки
<< предыдущая заметкаследующая заметка >>
22 июля 2011
странный глюк MySQL обнаружился

UPD: Спасибо, все исправил. Заодно обнаружился аццкий маразмище в работе с базой (чем старее собственные исходники, тем больше к ним ненависти, когда натыкаюсь ;). Спасибо anvm за совет. Опуская подробности, было так:

$mm=ms("SELECT DISTINCT `tag` FROM `dnevnik_tags` ORDER BY COUNT(`tag`)");
$a=array();
foreach($mm as $m) $a[$m['tag']]=ms("SELECT COUNT(*) FROM `dnevnik_tags` WHERE `tag`='".e($m['tag'])."'");
arsort($a);
foreach($a as $l=>$n) echo "<br>".h($l)." - ".$n;

Стало так:

$m=ms("SELECT `tag`, count(*) AS `n` FROM `dnevnik_tags` GROUP BY `tag` ORDER BY `n` DESC");
foreach($m as $n) echo "<br>".h($n['tag'])." - ".$n['n'];

:)))))


ИСХОДНЫЙ ТЕКСТ ЗАМЕТКИ:

С переездом на новый хостинг (видимо, другая версия MySQL) обнаружилось, что перестала работать вот такая конструкция:
SELECT DISTINCT `tag` FROM `dnevnik_tags` ORDER BY COUNT(`tag`)
Ее можно увидеть, если в дневнике (лучше в дневнике, а не в блоге): найти любую заметку с тегами и ткнуть в «тэги записи». Идея опции была в том, чтобы вывести на экран все имеющиеся тэги, отсортировав по количеству их использования в заметках. Раньше работало.

При этом исправно работает более простая конструкция:
SELECT DISTINCT `tag` FROM `dnevnik_tags`
Выдает все 48 имеющихся в налиции тэгов, но только не сортирует их по частоте использования.

Первый вариант глючит адски — либо выдает 0, либо 48 раз один и тот же (!) кусок фразы: «ть в такую чепуху, но романтик Энджер на такое должен был клюнуть — тем более, что и сам был на той же выставке и видел то же, что и Борден. Только вот Борден просчитался — оказалось, что свою репутацию Тесла заработал не просто та» (это мусор из чьего-то коммента, в таблице `dnevnik_tags` ничего подобного нет и быть не может), а после выполнения команд:
CHECK TABLE `dnevnik_tags`
ANALYZE TABLE `dnevnik_tags`
FLUSH TABLE `dnevnik_tags`
Стало еще лучше: «Ъy· [email protected]ЇяяяяР|{·`—!Ї яяяяР|{·—!Їё—!Їё—!Ї Р|{·Ё—!Їи–!ЇР|{·[email protected]Ї[email protected]Їр»

На старой версии MySQL все работало. Интересно, что это? Аномальная жара в Германии или глюк версии?

PS: Я вспомнил: обычно когда я пишу в блог подобные вещи, меня первым делом просят показать структуру базы. Показываю:


CREATE TABLE IF NOT EXISTS `dnevnik_tags` (
`num` int(10) unsigned NOT NULL COMMENT 'id заметки',
`tag` varchar(128) NOT NULL COMMENT 'имя тэга',
PRIMARY KEY (`num`,`tag`),
KEY `tag` (`tag`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

--
-- Дамп данных таблицы `dnevnik_tags`
--

INSERT INTO `dnevnik_tags` (`num`, `tag`) VALUES
(0, 'кино'),
(893, 'Орленок'),
(1067, 'стихи'),
(1080, 'rip'),
(1106, 'лекции о писательском деле'),
(1107, 'лекции о писательском деле'),
(1134, 'Орленок'),
(1142, 'лекции о писательском деле'),
(1218, 'Мексика-2009'),
(1218, 'поездка'),
(1219, 'Мексика-2009'),
(1219, 'поездка'),
(1222, 'Мексика-2009'),
(1222, 'поездка'),
[...]

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
Windows Safari Chrome
0
0
это не баг, а как раз логичное поведение более свежей версии mysql.

раньше SQL был не корректным, потому что должен был сортировать все записи согласно общему количеству записей в таблице. зная, что количество тагов = 48 и подставив вместо mysql это значение в ORDER BY, можно примерно представить "логику размышлений" базы данных.

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


проверочные запросы
плохой:

SELECT `tag` , COUNT( tag )
FROM `dnevnik_tags`
ORDER BY COUNT( tag )

хороший:

SELECT `tag` , COUNT( tag )
FROM `dnevnik_tags`
GROUP BY tag
ORDER BY COUNT( tag );
Linux Firefox
 Москва
0
0
Не вдаваясь в суть анализа запросов, я не очень вижу логику в поведении MySQL - она выдавала просто случайный набор символов из оперативной памяти.

Какой бы некорректный ни был запрос, это логичное поведение свежей версии - кидать произвольный мусор из кэша вместо ответа или сообщения об ошибке? :)
Mac Safari Chrome
0
0
Eugene Bond (#1025103)
мне вчера удалось путем переключения sql mode (http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html) добиться выбора подобного мусора. объяснить это не так сложно: если включен режим совместимости запросов, то такой запрос не будет неправильным (он же совместим). в то же время, данные все равно не могут быть получены в том виде, в котором они ожидаются, поэтому происходит выбор "мусора" (данных нет, но показать что-то надо)

PS:
уведомления не ходят. + старая восстановленная авторизация опять "слетела"
Linux Firefox
 Москва
0
0
Да, тогда вопрос к вам.

Допустим, есть таблица ZAMETKI:

`num` - номер заметки
`text` - текст заметки
`count_old` - счетчик посещений этой заметки до прошлого месяца

И таблица POSETIL - посещения заметок посетителями за последний месяц:
`num` - номер заметки
`IP` - посетитель

Для каждой заметки (допустим, заметка номер 4) число посещений арифметически складывается из двух чисел - старый счетчик + посещения по базе за последний месяц:
SELECT `count_old` FROM `ZAMETKI` WHERE `num`=4
SELECT count(*) FROM `POSETIL` WHERE `num`=4

Робкий вопрос: а нельзя ли это как-то записать в одном запросе, причем для всех заметок сразу? ;)
Mac Safari Chrome
0
0
Eugene Bond (#1025103)
не совсем понял что именно нужно. вот это?

SELECT count_old + COUNT(p.num) AS total, z.num FROM zametki AS z LEFT JOIN posetil AS p USING (num) GROUP BY num
<< предыдущая заметка следующая заметка >>