MySql Vreemd (voor mij) Prestatie op waar-clausule

Ik heb een tabel waarin 2k-records worden opgeslagen. Het schema is:

CREATE TABLE `tcms_articles` (
  `Id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `User_id` int(10) unsigned DEFAULT NULL,
  `Category_id` int(10) unsigned DEFAULT NULL,
  `Title` varchar(255) DEFAULT NULL,
  `Value` longtext,
  `Keywords` varchar(255) NOT NULL DEFAULT '',
  `Description` varchar(255) NOT NULL DEFAULT '',
  `Images` longtext NOT NULL,
  `Votes` int(10) unsigned NOT NULL DEFAULT '1',
  `Votes_sum` int(10) unsigned NOT NULL DEFAULT '5',
  `Views` int(10) unsigned NOT NULL DEFAULT '0',
  `Isvisible` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `Isfrontpage` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `Istoparticle` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `Expires_date` datetime NOT NULL DEFAULT '2099-12-31 00:00:00',
  `Date` datetime NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `article_users` (`User_id`) USING BTREE,
  KEY `article_section` (`Category_id`) USING BTREE,
  KEY `Isvisible_index` (`Isvisible`) USING BTREE,
  KEY `Istoparticle_index` (`Istoparticle`) USING BTREE,
  KEY `Expires_date_index` (`Expires_date`) USING BTREE,
  KEY `isfrontpage` (`Isfrontpage`) USING BTREE,
  KEY `Date_index` (`Date`) USING BTREE,
  CONSTRAINT `tcms_articles_categories` FOREIGN KEY (`Category_id`) REFERENCES `tcms_categories` (`Id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `tcms_articles_ibfk_2` FOREIGN KEY (`User_id`) REFERENCES `tcms_users` (`Id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=80 DEFAULT CHARSET=utf8;

Wanneer ik met deze query in de tabel zoek, heb ik prestatieproblemen

selecteer de waarde van tcms_articles waar istoparticle = 1 en isvisible = 1 volgorde op datumlimiet 1;

het duurt ongeveer 1,50+ seconden!

Maar als ik zo zoek:

selecteer waarde uit tcms_articles waarbij istoparticle = 1 volgorde op datumlimiet 1;

Ik heb geen probleem, het duurt ongeveer 0,02 seconden.

Heel erg bedankt.

2
Is dit de uitvoer van SHOW CREATE TABLE tcms_articles; ? Ik betwijfel het op een of andere manier. Kun je dat posten?
toegevoegd de auteur ypercubeᵀᴹ, de bron
MySQL voert meestal backquotes uit, geen enkele aanhalingstekens. Nooit gezien, ik dacht niet eens dat het mogelijk was.
toegevoegd de auteur ypercubeᵀᴹ, de bron
Nu gaat het goed, Thnx. Het is gemakkelijker voor anderen om te testen of je code hebt die net kan worden gekopieerd en geplakt (en wordt uitgevoerd zonder verandering). U kunt ook SQL-Fiddle gebruiken om de tabellen (en mogelijk enkele rijen) voor te bereiden zodat anderen kunnen testen, zelfs zonder met uw DBMS in hun machine.
toegevoegd de auteur ypercubeᵀᴹ, de bron
Waarom, zodat u het moeilijk maakt voor anderen om te kopiëren en te testen? Je hebt ook de KEY index_name GEBRUIKEND HASH (kolom) gewijzigd in KEY index_name (kolom) GEBRUIK VAN HASH ...
toegevoegd de auteur ypercubeᵀᴹ, de bron
Overweeg een samengestelde index te plaatsen op velden (istoparticle, isvisible) .
toegevoegd de auteur Zane Bien, de bron
Zie databasejournal.com/features /mysql/article.php/1382791/… Gebruik EXPLAIN op uw SELECT en zie welke indexen deze gebruikt. Ik denk niet dat het er een zal gebruiken en is in feite tafel-scanning.
toegevoegd de auteur Andrew Leach, de bron
Als u indexen laat vallen en opnieuw maakt, worden de statistieken opnieuw gegenereerd. Het is een goed idee om deze zo nu en dan te regenereren. Zie OPTIMIZE op pagina drie van mijn link.
toegevoegd de auteur Andrew Leach, de bron
Als ik jou was, zou ik proberen de index te laten vallen en opnieuw te doen. Heeft me eerder geholpen.
toegevoegd de auteur J A, de bron
@ypercube Ja, dit is de uitvoer. Waarom?
toegevoegd de auteur Sanosay, de bron
Het spijt me maar ik heb dit gedaan omdat ik formatteringsproblemen heb bij het plaatsen van deze vraag. Ik zal het veranderen.
toegevoegd de auteur Sanosay, de bron
Ik heb ze vervangen door '' ". Maar dit is geen probleem.
toegevoegd de auteur Sanosay, de bron
Het probleem was dat ik problemen had met indexen. Het interesse was dat "uitleggen" zegt dat het de indexen gebruikt .... raar: /
toegevoegd de auteur Sanosay, de bron
Ik heb zojuist composite index toegevoegd maar niets meer: ​​/ @Andrew ik heb dit gedaan, maar er staat dat het gebruikt: /
toegevoegd de auteur Sanosay, de bron
het is niet alleen istoparticle, isvisible etc.
toegevoegd de auteur Sanosay, de bron

1 antwoord

U kunt een B-tree (geen Hash) samengestelde index toevoegen aan (Istarticle, Isvisible, Date) voor deze query.

1
toegevoegd
Kun je de EXPLAIN weergeven met en zonder deze index?
toegevoegd de auteur ypercubeᵀᴹ, de bron
Nu heb ik het probleem opgelost (zoals ik zeg), en ik heb de uitvoer van uitleg niet.
toegevoegd de auteur Sanosay, de bron
Bedankt maar ik heb dat gedaan. Het lijkt erop dat ik indexen heb gesplitst die ik 2-3 keer niets heb laten vallen. Op de een of andere manier toen ik weer indexen haalde, werkt het op magische wijze.
toegevoegd de auteur Sanosay, de bron