Résultats MySQL incohérents avec Date() select

Que se passe-t-il ici? BTW, version du serveur MySQL: 5.0.45-log Distribution de source.Résultats MySQL incohérents avec Date() select

mysql> select count(*) 
     from notes 
     where date(updated_at) > date('2010-03-25'); 
+----------+ 
| count(*) | 
+----------+ 
|  0 | 
+----------+ 
1 row in set (0.59 sec) 

mysql> select count(*) 
     from notes 
     where message like'%***%' 
      and date(updated_at) > date('2010-03-25'); 
+----------+ 
| count(*) | 
+----------+ 
|  26 | 
+----------+ 
1 row in set (1.30 sec) 

mysql> explain select count(*) 
     from notes 
     where date(updated_at) > date('2010-03-25'); 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
| 1 | SIMPLE  | notes | ALL | NULL   | NULL | NULL | NULL | 588106 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
1 row in set (0.07 sec) 

mysql> explain select updated_at 
     from notes 
     where message like'%***%' 
      and date(updated_at) > date('2010-03-25'); 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
| 1 | SIMPLE  | notes | ALL | NULL   | NULL | NULL | NULL | 588106 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+ 
1 row in set (0.09 sec) 

mysql>

Voici le schéma de la table.

CREATE TABLE `notes` (
`id` int(11) NOT NULL auto_increment, 
`status` varchar(255) default NULL, 
`message` text, 
`noteable_id` int(11) default NULL, 
`noteable_type` varchar(255) default NULL, 
`deleted_at` datetime default NULL, 
`creator_id` int(11) default NULL, 
`updater_id` int(11) default NULL, 
`deleter_id` int(11) default NULL, 
`created_at` datetime default NULL, 
`updated_at` datetime default NULL, 
`public` tinyint(1) default '0', 
`forced` tinyint(1) default '0', 
`agent_created_at` datetime default NULL, 
PRIMARY KEY (`id`), 
KEY `noteable_id` (`noteable_id`), 
KEY `deleted_at` (`deleted_at`), 
KEY `noteable_type` (`noteable_type`(10)), 
KEY `creator_id` (`creator_id`), 
KEY `status` (`status`), 
KEY `created_at` (`created_at`) 
) ENGINE=InnoDB AUTO_INCREMENT=613168 DEFAULT CHARSET=latin1

Source

2010-03-26 Jag the Reducer

non, rien changé . Je peux continuer à essayer les deux requêtes et obtenir les mêmes résultats incohérents à plusieurs reprises. –

Veuillez publier le schéma de votre table et indiquer le moteur et la version que vous utilisez. – MarkR

Publié. En outre, j'ai essayé de décharger/importer la table et je commence à obtenir des résultats cohérents. Il semble que la base de données ait été corrompue. –

Il s'avère que cette instance particulière n'était pas due à une corruption de la base de données, mais à un bogue dans la fonction Date pour MySQL version 5.0.45 (+?).

http://bugs.mysql.com/bug.php?id=32159

Nous ne voyons pas la nécessité de réagir à cette situation immédiatement, mais nous allons transférer à une version plus récente de MySQL (soit 5.0.77+ ou 5.1)

Source

2010-03-31 02:31:39

Si la table est petite, essayer de mettre & rechargeant sur un serveur frais sur une autre boîte (avec la même version). Si le problème disparaît, il existe une corruption interne et vous devrez soit recharger la table sur le serveur existant, soit réinjecter la base de données entière à partir d'un vidage.

Si le comportement est reproductible sur une base de données propre et que personne ne peut l'expliquer (après avoir publié le schéma, etc.), alors déclenchez un bogue.

Source

2010-03-26 23:27:12 MarkR

Lorsque j'ai essayé, les requêtes étaient en effet cohérentes. Nous utilisons la réplication maître-esclave (et le maître est corrompu), alors quelle est la meilleure façon de recharger ces données? –

Si la table est petite, essayez mysqldumping et rechargement (cela aura un impact sur la disponibilité du service). Si la table est grande, essayez différentes options sur vos systèmes de test, j'ai trouvé mk-parallel-dump assez rapide mais pas encore rapide. SELECT INTO OUTFILE suivi de LOAD DATA INFILE fonctionne également. Expérimentez avec des données de taille de production sur un système de non-production. – MarkR

Résultats MySQL incohérents avec Date() select

Répondre

Questions connexes