sql >> Databasteknik >  >> RDS >> Mysql

Är det bättre att filtrera en resultatuppsättning med hjälp av en WHERE-sats eller med applikationskod?

Tumregeln för alla program är att låta DB göra de saker den gör bra:filtrering, sortering och sammanfogning.

Separera frågorna i sina egna funktioner eller klassmetoder:

$men = $foo->fetchMaleUsers();
$women = $foo->fetchFemaleUsers();

Uppdatera

Jag tog Stevens PostgreSQL-demonstration av en fullständig tabellsökningsfråga som presterade dubbelt så bra som två separata indexerade frågor och härmade den med MySQL (som används i själva frågan):

Schema

CREATE TABLE `gender_test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `gender` enum('male','female') NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=26017396 DEFAULT CHARSET=utf8

Jag ändrade könstypen till att inte vara en VARCHAR(20) eftersom den är mer realistisk för den här kolumnen. Jag tillhandahåller också en primärnyckel som du kan förvänta dig på en tabell istället för ett godtyckligt DUBBELt värde.

Oindexerade resultat

mysql> select sql_no_cache * from gender_test WHERE gender = 'male';

12995993 rows in set (31.72 sec)

mysql> select sql_no_cache * from gender_test WHERE gender = 'female';

13004007 rows in set (31.52 sec)

mysql> select sql_no_cache * from gender_test;

26000000 rows in set (32.95 sec)

Jag litar på att detta inte behöver någon förklaring.

Indexerade resultat

ALTER TABLE gender_test ADD INDEX (gender);

...

mysql> select sql_no_cache * from gender_test WHERE gender = 'male';

12995993 rows in set (15.97 sec)

mysql> select sql_no_cache * from gender_test WHERE gender = 'female';

13004007 rows in set (15.65 sec)

mysql> select sql_no_cache * from gender_test;

26000000 rows in set (27.80 sec)

Resultaten som visas här är radikalt skiljer sig från Stevens data. De indexerade frågorna utför nästan dubbelt så snabbt som hela tabellskanningen. Det här är från en korrekt indexerad tabell med kolumndefinitioner för sunt förnuft. Jag känner inte till PostgreSQL alls, men det måste finnas någon betydande felkonfiguration i Stevens exempel för att inte visa liknande resultat.

Med tanke på PostgreSQL:s rykte om att göra saker bättre än MySQL, eller åtminstone lika bra som, vågar jag påstå att PostgreSql skulle visa liknande prestanda om den används på rätt sätt.

Observera också att på samma maskin tar en alltför förenklad loop som gör 52 miljoner jämförelser ytterligare 7,3 sekunder att utföra.

<?php
$N = 52000000;
for($i = 0; $i < $N; $i++) {
    if (true == true) {
    }
}

Jag tror att det är ganska uppenbart vad som är det bättre tillvägagångssättet med dessa data.



  1. Stöder MySQL Regexp Unicode-matchning

  2. Vad är nytt i ProxySQL 2.0

  3. hur man undviker avgränsaren från kolumninnehållet vid export av csv

  4. Varför använda join istället för var i MySQL-frågor?