J'ai une requête qui a l'air très simple. Cependant, si je combine la commande et limitez, la performance diminue par des échelles. J'ai trouvé plusieurs questions sur la performance limitée de MySQL dans de grandes tables, mais je ne pense pas que ceci est la Cuase ici, car sans aucune limite, la requête ne trouve pas.
Voici les requêtes dans la "complexité" croissante p>
CREATE TABLE `mytable` (
`data` VARCHAR(32) NOT NULL COLLATE 'ascii_bin',
`mailing` INT(10,0) NOT NULL,
`token` VARCHAR(64) NULL DEFAULT NULL COLLATE 'ascii_bin',
`section` INT(10,0) NOT NULL,
`expiry` INT(10,0) NULL DEFAULT NULL,
PRIMARY KEY (`data`) USING BTREE,
INDEX `mailing_CS` (`mailing`) USING BTREE,
INDEX `section_CS` (`section`) USING BTREE,
CONSTRAINT `mailing_CS` FOREIGN KEY (`mailing`) REFERENCES `mydata`.`mailings` (`id`) ON UPDATE NO ACTION ON DELETE CASCADE,
CONSTRAINT `section_CS` FOREIGN KEY (`section`) REFERENCES `mydata`.`sections` (`id`) ON UPDATE NO ACTION ON DELETE CASCADE
)
COLLATE='ascii_bin'
ENGINE=InnoDB
;
section code> (et autres), mais pas pour jeton code> li>
ul> Voici la structure de la table: P>
SELECT * FROM `mydata`.`mytable` WHERE ((token='XFRA1NMDU9XY') AND (section=210874));
/* Rows: 0 Time: 0,094 sec. */
SELECT * FROM `mydata`.`mytable` WHERE ((token='XFRA1NMDU9XY') AND (section=210874)) LIMIT 1;
/* Rows: 0 Time: 0,063 sec. */
SELECT * FROM `mydata`.`mytable` WHERE ((token='XFRA1NMDU9XY') AND (section=210874)) ORDER BY mailing;
/* Rows: 0 Time: 0,125 sec. */
SELECT * FROM `mydata`.`mytable` WHERE ((token='XFRA1NMDU9XY') AND (section=210874)) ORDER BY mailing LIMIT 1;
/* Rows: 0 Time: 45,500 sec. */
3 Réponses :
Je pense que mysql tente d'utiliser Essayez cette requête: P> mailing_cs code> index dans la dernière requête et cet index n'est pas optimal. SELECT *
FROM `mydata`.`mytable` USE INDEX (section_CS) IGNORE INDEX(mailing_CS)
WHERE (
(token = 'XFRA1NMDU9XY') AND
(section = 210874)
)
ORDER BY mailing
LIMIT 1
L'ordre MySQL par la limite est l'utilisation la plus courante de la commande par des applications interactives avec de grands ensembles de données triés.
Assurez-vous qu'il utilise Index . Il est très important d'avoir commandé par la limite exécutée sans balayer et trier le jeu de résultats complets, il est donc important que celui-ci utilise index - dans ce cas, l'analyse de la plage d'index sera démarrée et l'exécution de requête arrêtée dès que la quantité de lignes requise généré.
Par exemple, si je sélectionne * à partir de la commande de sites par date_created Desc Limite 10; J'utiliserais l'index sur (date_created) pour obtenir un ensemble de résultats très rapide.
maintenant et si j'ai quelque chose comme SELECT * à partir de sites sur la catégorie_id = 5 de la commande par date_created Desc Limite 10;
Dans ce cas, l'indice de Date_Created peut également fonctionner, mais il pourrait ne pas être le plus efficace - s'il s'agit d'une catégorie rare, une grande partie de la table peut être numérisée pour trouver 10 rangées. Alors index sur (catégorie_id, date_created) sera une meilleure idée.
indexation peut vous aider !!
INDEX(token, section, mailing) INDEX(section, token, mailing)
Expliquez votre chaîne SQL
Je ne peux pas voir l'expliquer
Quel client (ligne de commande, workbench, phpmyadmin, etc.) utilisez-vous pour obtenir les horaires?