2010-11-02 14 views
2

Tout d'abord, voici la table:MariaDB, PBXT et mystérieuse requête résultats

CREATE TABLE `outlet_tags` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `importer_id` int(11) NOT NULL, 
    `outlet_id` int(11) NOT NULL, 
    `code` varchar(20) NOT NULL, 
    `postcode` varchar(15) DEFAULT NULL, 
    `tag_set` varchar(45) DEFAULT NULL, 
    `tag_type` varchar(45) DEFAULT NULL, 
    `tag_details` varchar(100) DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `fk_report_outlet_tags_1` (`importer_id`), 
    KEY `fk_report_outlet_tags_2` (`outlet_id`), 
    KEY `outlet_tag_set` (`tag_set`), 
    KEY `outlet_tag_type` (`tag_type`), 
    KEY `outlet_tag_details` (`tag_details`), 
    CONSTRAINT `fk_report_outlet_tags_1` FOREIGN KEY (`importer_id`) REFERENCES `importers` (`id`), 
    CONSTRAINT `fk_report_outlet_tags_2` FOREIGN KEY (`outlet_id`) REFERENCES `outlets` (`id`) 
) ENGINE=PBXT DEFAULT CHARSET=utf8; 

Quelqu'un peut-il faire la lumière sur la raison pour laquelle les valeurs de champ changent en fonction des conditions utilisées dans les requêtes suivantes? Cela n'arrive pas si le moteur est Maria.

select * from outlet_tags where code=1503 and outlet_id=407 limit 3; 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
| id | importer_id | outlet_id | code | postcode | tag_set | tag_type  | tag_details | 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
| 222 |   1 |  407 | 1503 | XXX XXX | outlet | Make up   | Make up  | 
| 675 |   1 |  407 | 1503 | XXX XXX | outlet | Approved Status | Approved  | 
| 1619 |   1 |  407 | 1503 | XXX XXX | outlet | Retail Area  | No Retail Area | 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
3 rows in set (0.00 sec) 

select * from outlet_tags where code=1503 and importer_id=1 limit 3; 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
| id | importer_id | outlet_id | code | postcode | tag_set | tag_type  | tag_details | 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
| 222 |   1 |  407 | 1503 | XXX XXX | outlet | Make up   | Make up  | 
| 675 |   1 |  407 | 1503 | XXX XXX | outlet | Approved Status | Approved  | 
| 1619 |   1 |  407 | 1503 | XXX XXX | outlet | Retail Area  | No Retail Area | 
+------+-------------+-----------+------+----------+---------+-----------------+----------------+ 
3 rows in set (0.00 sec) 

select * from outlet_tags where importer_id=1 and outlet_id=407 limit 3; 
+------+-------------+-----------+------+----------+---------+----------+-------------+ 
| id | importer_id | outlet_id | code | postcode | tag_set | tag_type | tag_details | 
+------+-------------+-----------+------+----------+---------+----------+-------------+ 
| 222 |   1 |  407 | 1503 | NULL  | NULL | NULL  | NULL  | 
| 675 |   1 |  407 | 1503 | NULL  | NULL | NULL  | NULL  | 
| 1619 |   1 |  407 | 1503 | NULL  | NULL | NULL  | NULL  | 
+------+-------------+-----------+------+----------+---------+----------+-------------+ 
3 rows in set (0.00 sec) 

Mise à jour: à partir de MariaDB 5,5 PBXT was dropped as a storage engine

+0

Est-ce que quelqu'un pense que cela aurait pu être de mauvaises données d'index causant les valeurs NULL? La troisième requête est la seule à n'utiliser que des champs indexés dans la condition WHERE – Cez

Répondre

1

Essayez d'utiliser une clause ORDER BY avec les requêtes.

Différents moteurs peuvent renvoyer des lignes dans un ordre différent en fonction de la façon dont les lignes sont récupérées.

+2

Merci d'avoir ramené celui-ci d'entre les morts! Je ne suis pas sûr de comprendre votre commentaire. Les lignes qui sont retournées par les 3 requêtes ont des PK correspondants et sont donc les mêmes lignes, mais la troisième requête a des valeurs NULL où les 2 autres ont des données valides. – Cez