[PHP/(My)SQL] voor dummies #110

Index

» digital corner

» development

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_128309791
quote:
0s.gif Op woensdag 26 juni 2013 11:30 schreef mstx het volgende:
Ik heb zelf ook een vraagje, deze (simpele) query is soms traag:
[ code verwijderd ]

De explain zegt dit:
[ code verwijderd ]

Kan dat sneller?
Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.
fokstok.nl
  donderdag 27 juni 2013 @ 08:04:40 #52
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128310161
quote:
14s.gif Op donderdag 27 juni 2013 00:47 schreef Boze_Appel het volgende:

[..]

Indexes erbij maken op type en isactive. Daar doe je de selecties op.
Die indexes zitten er al op.

quote:
0s.gif Op donderdag 27 juni 2013 07:16 schreef Light het volgende:

[..]

Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.
Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?

Nog wat dingen geprobeerd maar het probleem zit hem echt in de COUNT() i.c.m. JOIN.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17		SELECT COUNT(*) FROM TabelA
= 0.0002 sec

SELECT COUNT(*) FROM TabelA LEFT JOIN TabelB.................
= 0.25 sec

SELECT COUNT(*) FROM TabelA INNER JOIN TabelB.................
= 0.4 sec

SELECT * FROM TabelA LEFT JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA INNER JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA
= 0.0004 sec

Ik denk dat ik maar gewoon de kolom van TabelB die ik in de WHERE gebruik kopieer naar TabelA zodat ik niet hoef te joinen.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_128310218
quote:
11s.gif Op donderdag 27 juni 2013 08:04 schreef mstx het volgende:

Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?
Nee.
Bij een left join selecteer je alle rijen uit A en als er geen match in B gevonden kan worden (op basis van de ON clause) dan worden alle velden van B voor die rij gevuld met NULL.
Bij een inner join selecteer je alleen die rijen uit A waarvoor een match in B gevonden kan worden (op basis van de ON clause).
fokstok.nl
  donderdag 27 juni 2013 @ 08:22:45 #54
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128310344
Ho ik zat even niet op te letten, je hebt gelijk. :P
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  donderdag 27 juni 2013 @ 08:31:58 #55
187069 slacker_nl
Sicko pur sang
pi_128310447
quote:
0s.gif Op donderdag 27 juni 2013 07:00 schreef Chandler het volgende:
Ik voer verder niets specifieks uit met curl, ik gebruik dezelfde opzet als die eerder door Slacker_nl is gegeven (DIG / [PHP/(My)SQL] voor dummies #109)

En het uitlezen van de DNS per URL zou een mogelijkheid zijn, al zou CURL deze url natuurlijk ook gewoon moeten kunnen vinden :{
Mijn code is altijd bugfree :P
In theory there is no difference between theory and practice. In practice there is.
  donderdag 27 juni 2013 @ 08:33:07 #56
267443 Cue_
Cuecumbergirl
pi_128310463
Mensen hier ervaring/voorbeelden van een soap call naar een webservice met PL/SQL?
pi_128312572
quote:
10s.gif Op donderdag 27 juni 2013 08:31 schreef slacker_nl het volgende:

[..]

Mijn code is altijd bugfree :P
juist haha

maar goed, blijkbaar doe ik iets verkeerd!? ik ga nu eens kijken hoe anderen het doen...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  donderdag 27 juni 2013 @ 13:39:43 #58
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128320001
Ik kwam net weer eens een prachtige query tegen van een oud-collega:
1
2
3
4
5
6
7
8
9
10
11
12
13		SELECT 
 kolommen
FROM
 tabel 
WHERE 
 id IN (
          SELECT 
            id 
          FROM
            tabel 
          WHERE 
           voorwaarde=1
         )
_O_ (het is dezelfde tabel)
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_128320058
Prachtig! zo leer je sub selects :+
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  donderdag 27 juni 2013 @ 16:00:42 #60
118585 Crutch
Filantroop || Taalzwengel
pi_128325444
Hallo! Wat vinden jullie van Symfony?
Je moeder is een hamster
pi_128329074
quote:
0s.gif Op donderdag 27 juni 2013 13:39 schreef mstx het volgende:
Ik kwam net weer eens een prachtige query tegen van een oud-collega:
[ code verwijderd ]

_O_ (het is dezelfde tabel)
Als het nou op een ander veld was het helemaal niet zo gek geweest, voorbeeld is een werknemerstabel waarbij er een veld leidinggevende is welke correspondeerd met het werknemerId.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
pi_128421826
Ik wil temperatuur in een Mysql database opslaan, maar zit even te twijfelen wat ik het beste kan gebruiken. Float, Double, Decimal of Real?

Mijn eerste keuze zou een float zijn, maar ik weet dat als je geld opslaat in een DB dat je Decimal moet gebruiken, aangezien temperatuur aardig op geld lijkt (ook twee cijfers achter de komma [in ieder geval hoe ik het aangeleverd krijg]). Zou ik zeggen Decimal is een veilig keuze, maar ik ga niet rekenen met deze cijfers, dus Float zou volgens mij ook wel kunnen.

Kan iemand de beste keuze kunnen uitleggen en wat standaarden hiervoor zijn?
  † In Memoriam † zondag 30 juni 2013 @ 15:42:05 #63
159335 Boze_Appel
Vrij Fruit
pi_128422313
quote:
0s.gif Op zondag 30 juni 2013 15:29 schreef Pakspul het volgende:
Ik wil temperatuur in een Mysql database opslaan, maar zit even te twijfelen wat ik het beste kan gebruiken. Float, Double, Decimal of Real?

Mijn eerste keuze zou een float zijn, maar ik weet dat als je geld opslaat in een DB dat je Decimal moet gebruiken, aangezien temperatuur aardig op geld lijkt (ook twee cijfers achter de komma [in ieder geval hoe ik het aangeleverd krijg]). Zou ik zeggen Decimal is een veilig keuze, maar ik ga niet rekenen met deze cijfers, dus Float zou volgens mij ook wel kunnen.

Kan iemand de beste keuze kunnen uitleggen en wat standaarden hiervoor zijn?
Als je er niet mee gaat rekenen, waarom sla je ze dan op?

Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Carpe Libertatem
pi_128425070
quote:
7s.gif Op zondag 30 juni 2013 15:42 schreef Boze_Appel het volgende:

[..]

Als je er niet mee gaat rekenen, waarom sla je ze dan op?
Niet mee rekenen in de zin van ik ga geen percentages er over heen gooien om daarna totalen te gaan berekenen. Meer datamining, zodat ik later kan kijken of ik ze kan gebruiken om beslissingen op te maken.
quote:
Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Arduino zit er achter, vet dure apparatuur dus :P
pi_128441331
quote:
7s.gif Op zondag 30 juni 2013 15:42 schreef Boze_Appel het volgende:

[..]

Als je er niet mee gaat rekenen, waarom sla je ze dan op?

Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Als je twee decimalen aangeleverd krijgt, waarom zou je er dan maar 1 opslaan?
fokstok.nl
  † In Memoriam † zondag 30 juni 2013 @ 23:38:39 #66
159335 Boze_Appel
Vrij Fruit
pi_128441546
quote:
0s.gif Op zondag 30 juni 2013 23:33 schreef Light het volgende:

[..]

Als je twee decimalen aangeleverd krijgt, waarom zou je er dan maar 1 opslaan?
Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
Carpe Libertatem
pi_128441555
Gebruik gewoon een int en sla de temp. in honderdste graden celcius op.
zcflevo.nl
pi_128442945
quote:
7s.gif Op zondag 30 juni 2013 23:38 schreef Boze_Appel het volgende:

[..]

Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
quote:
7s.gif Op zondag 30 juni 2013 23:38 schreef Boze_Appel het volgende:

[..]

Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
Dat ligt er m.i. ook aan wat je meet. Kamertemperatuur in honderdste graden is niet echt zinnig maar bij een experiment kan die nauwkeurigheid wel nuttig zijn.
fokstok.nl
  † In Memoriam † maandag 1 juli 2013 @ 00:25:14 #69
159335 Boze_Appel
Vrij Fruit
pi_128443610
quote:
0s.gif Op maandag 1 juli 2013 00:09 schreef Light het volgende:

Dat ligt er m.i. ook aan wat je meet. Kamertemperatuur in honderdste graden is niet echt zinnig maar bij een experiment kan die nauwkeurigheid wel nuttig zijn.
Eens, maar als er al aangegeven wordt er niet mee te willen rekenen kan je 'experiment' meteen wel uitsluiten. ;)
Carpe Libertatem
pi_128446863
tvp, ben bezig met een site voor mn pa, dus ik ga jullie waarschijnlijk nog wel lastig vallen :)
pi_128529606
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  woensdag 3 juli 2013 @ 10:37:05 #72
178193 Juicyhil
Bekende FOK!ker
pi_128529695
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Lees je hem tegelijkertijd van de harde schijf af? Dat gaat namelijk altijd langzaam. Eerst in het geheugen stoppen en daarna pas checken met regex.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
pi_128529759
het hele document zit in het geheugen! :) dus dat is het probleem niet...

Sterker nog, het document wordt geladen in het geheugen vanaf een andere server (curl) en daarna pas door een foreach loopje bewerkt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22		<?php
        $t = time();
        $parseCls  = new parse();
        $size = 1000;
        echo '<pre>';
        if (strlen($document) > $size)
        {
            $loop = ceil(strlen($document) / $size);
            $start = 0;
            for ($x = 0; $x < $loop; $x++)
            {
                echo date("Y-m-d H:i:s") . ' - ' . ($x * $size) . ' - ' . ($size + 500) . ' of ' . strlen($document) . '<br />';
                $start = substr($document, $x * $size, $size + 500);
                $parseCls->parse($start);
            }
        }
        else
        {
            print_r($parseCls->parse($document));
        }
        echo '</pre>';
?>


[ Bericht 41% gewijzigd door Chandler op 03-07-2013 10:46:37 ]
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  woensdag 3 juli 2013 @ 11:34:08 #74
25889 Sitethief
Fulltime Flapdrol
pi_128531465
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Some people, when confronted with a problem, think
“I know, I'll use regular expressions.” Now they have two problems.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht &gt;:)
  woensdag 3 juli 2013 @ 11:37:31 #75
187069 slacker_nl
Sicko pur sang
pi_128531585
quote:
0s.gif Op woensdag 3 juli 2013 10:37 schreef Juicyhil het volgende:

[..]

Lees je hem tegelijkertijd van de harde schijf af? Dat gaat namelijk altijd langzaam. Eerst in het geheugen stoppen en daarna pas checken met regex.
Gewoon telkens een x-aantal blokken lezen, dan parsen, dan weer verder lezen, dan parsen, etc etc. http://php.net/manual/en/function.fread.php Welk even flocken, anders gaan er andere processen naar willen schrijven en gaat het (mogelijk) fout.
In theory there is no difference between theory and practice. In practice there is.
pi_128531706
Dat doe ik dus nu, plus ik voeg 500 bytes extra toe om niets te missen... :D
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128532007
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Ja en nee. Dat hangt compleet van de gebruikte regex af. Een inefficiente regex kan (onnodig) lang duren, zeker als het om veel karakters gaat (oa ivm backtracking). Wat voor regex pattern gebruik je?
pi_128532386
"/[a-z0-9]+([_\\.-][a-z0-9]+)*@([a-z0-9]+([\.-][a-z0-9]+)*)+\\.[a-z]{2,}/i"

Om emails te parsen! :) ik krijg links met documenten aangeleverd die ik moet omzetten naar een database tabel...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128532931
Aha, de bekende email-regex :P

Ik zie een aantal nested quantifiers, wellicht is dit interessant leesvoer: Catastrophic backtracking.

Ik heb nu helaas niet de tijd om deze regex te optimaliseren, maar misschien wel een tip: probeer niet alles in een regex te vrotten. Je kunt ook ruwweg alle strings lijkende op emailadressen eruit halen en daarna de $matches array loopen voor een nadere validatiestap. Dus trek de filterstap en validatiestap wat uit elkaar.
  woensdag 3 juli 2013 @ 13:02:19 #80
187069 slacker_nl
Sicko pur sang
pi_128534603
quote:
0s.gif Op woensdag 3 juli 2013 12:00 schreef Chandler het volgende:
"/[a-z0-9]+([_\\.-][a-z0-9]+)*@([a-z0-9]+([\.-][a-z0-9]+)*)+\\.[a-z]{2,}/i"

Om emails te parsen! :) ik krijg links met documenten aangeleverd die ik moet omzetten naar een database tabel...
Alles achter de @ kan je hiertegen aangooien:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50		{                                                                                                                                                                         
    # The following is stolen from:
    # http://cpansearch.perl.org/src/CREIN/Regexp-Common-dns-0.00_01/lib/Regexp/Common/dns.pm
    # So we don't need to install the dependency which is not in the Debian repository
    #    
    sub _domain {
        my %flags = @_;

        my $sep = '\.';

        my $letter      = '[a-zA-Z]';
        my $let_dig     = '[a-zA-Z0-9]';
        my $let_dig_hyp = '[-a-zA-Z0-9]';

        my %labels = (
            1035   => "(?:$letter(?:$let_dig|$let_dig_hyp\{1,61}$let_dig)?)",
            1123   => "(?:(?:$let_dig|$let_dig$let_dig_hyp*$let_dig)$sep)*(?:$let_dig|$let_dig$let_dig_hyp*$let_dig)",
            2181   => '[^.]{1,63}',
            hybrid => '[a-zA-Z0-9_-]{1,63}'
        );   

        $flags{'-rfc'} ||= 1035;

        my $label = $labels{$flags{'-rfc'}} || die("Unknown DNS RFC: $flags{'-rfc'}");

        if ($flags{'-rfc'} ne 2181 && exists $flags{'-wildcard'} && not defined $flags{'-wildcard'}) {
            $label = "(?:\\*|$label)";
        }    

        my $quant = '*'; 
        if ($flags{'-minlabels'}) {
            $quant = '{' . ($flags{'-minlabels'} - 1) . ',}';
        }    

        return qr/^(?:$label$sep)$quant$label$sep?$/;
    }    

    my $fqdn_regexp = _domain(-rfc => 1123, -minlabels => 2);

    use constant VALID_FQDN => sub {
        my $fqdn = shift;
        if ($fqdn && $fqdn =~ m/$fqdn_regexp/) {
            $fqdn =~ s/\.$//;
            return 0 if (length($fqdn) > 255);
            return 0 if (grep { length($_) > 63 } split(/\./, $fqdn));
            return 1;
        }    
        return 0;
    };   
}

Je mag het zelf verphp'en. Dan kan je vervolgens alles voor de @ ook nog eens goed parsen en dan ben je klaar.
In theory there is no difference between theory and practice. In practice there is.
pi_128536936
En voor je het weet heb je zoiets: http://www.perlmonks.org/?node_id=393809 :X

Ik zou het lekker simpel houden. Als het even kan zou ik filter_var() (php >= 5.2.0) erbij betrekken voor de validatie.
pi_128540548
quote:
12s.gif Op woensdag 3 juli 2013 13:54 schreef zoem het volgende:
En voor je het weet heb je zoiets: http://www.perlmonks.org/?node_id=393809 :X

Ik zou het lekker simpel houden. Als het even kan zou ik filter_var() (php >= 5.2.0) erbij betrekken voor de validatie.
:D

filter_var gebruikt trouwens intern ook een enorme regex :P
..///
  maandag 8 juli 2013 @ 09:23:31 #83
25889 Sitethief
Fulltime Flapdrol
pi_128711732
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21		<?php
    public function compareValues($type,$compare1,$compare2){
        $count1 =0;
        $count2 =0;
        switch ($type) {
            case 'Doctype':
                $var = '\$v->data->doctype';
                break;

            default:
                break;
        }
        foreach($this->selectedData as $k=>$v){
            $val = 'empty';
            eval('$val = '.$var.';');
            if($val && $val === $compare1)++$count1;
            if($val && $val === $compare2)++$count2;
        }
        return $count1.$count2;
    }
?>

Ik wil deze functie gebruiken om dynamisch bepaalde waardes in een array met objecten te vergelijken. Het probleem is dat ik meerdere type data wil kunnen vergelijken die op meerdere plekken in het object zitten. Weet iemand of het mogelijk is om, met bijvoorbeeld eval, deze op een makkelijke manier dynamisch aan te maken? Anders moet ik die foreach in iedere case stoppen en dat vind ik toch niet een goede, beheersbare oplossing. Maar eval zelf is ook niet zo heel erg tof.

Wat ik tot nu toe kon vinden is dit alleen maar mogelijk bij statisch properties.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht &gt;:)
pi_128855608
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?

1
2
3
4
5
6
7		SELECT  `spider`.`id` AS spiderID,  
`spider`.`url` AS spiderURL,  
`spider`.`failed` AS spiderFailed
FROM  `spider` 
WHERE  `spider`.`project_id` =7
AND  `spider`.`processed` =0
LIMIT 1

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
1
2
3
4
5
6
7
8
9
10
11		CREATE TABLE IF NOT EXISTS `spider` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `project_id` bigint(20) unsigned NOT NULL,
  `url` varchar(255) NOT NULL,
  `processed` tinyint(1) NOT NULL DEFAULT '0',
  `failed` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `project_id_2` (`project_id`,`url`),
  KEY `failed` (`failed`),
  KEY `project_id` (`project_id`,`processed`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=103771614 ;

Iemand een idee? oh ik heb maar 17m regeltjes....
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128855743
Wat zegt EXPLAIN?
  donderdag 11 juli 2013 @ 23:49:58 #86
330295 Purplesparks
Lovercall baby
pi_128855903
quote:
0s.gif Op donderdag 11 juli 2013 23:42 schreef Chandler het volgende:
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?
[ code verwijderd ]

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
[ code verwijderd ]

Iemand een idee? oh ik heb maar 17m regeltjes....
Natuurlijk niet het antwoord wat je zoekt. Maar je kan het via een omweg ook gewoon orderen binnen php lijkt me.
Touching from a distance ~
  donderdag 11 juli 2013 @ 23:51:32 #87
178193 Juicyhil
Bekende FOK!ker
pi_128855961
quote:
0s.gif Op donderdag 11 juli 2013 23:49 schreef Purplesparks het volgende:

[..]

Natuurlijk niet het antwoord wat je zoekt. Maar je kan het via een omweg ook gewoon orderen binnen php lijkt me.
Dat gaat je geheugen kosten _O-
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
  donderdag 11 juli 2013 @ 23:52:46 #88
330295 Purplesparks
Lovercall baby
pi_128856016
quote:
0s.gif Op donderdag 11 juli 2013 23:51 schreef Juicyhil het volgende:

[..]

Dat gaat je geheugen kosten _O-
True dat, maar een potentiële mogelijkheid als chandler niet de oplossing weet te vinden van de lange order tijd.
Touching from a distance ~
  donderdag 11 juli 2013 @ 23:54:51 #89
178193 Juicyhil
Bekende FOK!ker
pi_128856114
quote:
0s.gif Op donderdag 11 juli 2013 23:42 schreef Chandler het volgende:
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?
[ code verwijderd ]

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
[ code verwijderd ]

Iemand een idee? oh ik heb maar 17m regeltjes....
Neem anders eens failed op in je where-clause. Dan hoeft hij in wat minder rijen te sorteren.
Edit: oh never mind, niet goed gelezen :P
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
pi_128856450
quote:
0s.gif Op donderdag 11 juli 2013 23:51 schreef Juicyhil het volgende:

[..]

Dat gaat je geheugen kosten _O-
Valt erg mee hoor als je het een beetje slim aanpakt, aangenomen dat er gewerkt wordt met een beperkte subset van de 17M rows (processed=0). Maar goed, de query optimaliseren heeft natuurlijk de voorkeur.

[ Bericht 0% gewijzigd door zoem op 12-07-2013 00:48:54 ]
pi_128865101
Ja, en het rare is dat er geen filesort gebruikt wordt, dus het orderen gebeurd toch echt wel in het geheugen (als ik check met explain). Dacht zelf ook dat ik de indexes goed had en dat blijkt wel, maar het vervelende blijft dat ik per query met order by een kleine 1000x zolang bezig ben...

Maar hebben jullie tips? oh en de beperkte set van 17m rows zijn in dit geval zo'n 0,5m rows :@

@zoom:

Zonder order by
1 SIMPLE spider ref project_id_2,project_id project_id 9 const,const 536370

Met order by
1 SIMPLE spider index project_id_2,project_id failed 1 NULL 39 Using where

[ Bericht 9% gewijzigd door Chandler op 12-07-2013 11:41:09 ]
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  vrijdag 12 juli 2013 @ 11:38:38 #92
330295 Purplesparks
Lovercall baby
pi_128865218
quote:
0s.gif Op vrijdag 12 juli 2013 11:35 schreef Chandler het volgende:
Ja, en het rare is dat er geen filesort gebruikt wordt, dus het orderen gebeurd toch echt wel in het geheugen (als ik check met explain). Dacht zelf ook dat ik de indexes goed had en dat blijkt wel, maar het vervelende blijft dat ik per query met order by een kleine 1000x zolang bezig ben...

Maar hebben jullie tips? oh en de beperkte set van 17m rows zijn in dit geval zo'n 3,5m rows :@
Gaat het ook zo traag wanneer je order by gebruikt in andere tabellen of alleen in deze?
Touching from a distance ~
pi_128865305
quote:
0s.gif Op vrijdag 12 juli 2013 11:38 schreef Purplesparks het volgende:

[..]

Gaat het ook zo traag wanneer je order by gebruikt in andere tabellen of alleen in deze?
Geen idee, rest van de tabellen zijn niet zo groot dus daar zal het allemaal wel meevallen... en daar zit het tijdsverlies in deze niet in....
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  vrijdag 12 juli 2013 @ 11:43:34 #94
330295 Purplesparks
Lovercall baby
pi_128865399
quote:
15s.gif Op vrijdag 12 juli 2013 11:40 schreef Chandler het volgende:

[..]

Geen idee, rest van de tabellen zijn niet zo groot dus daar zal het allemaal wel meevallen... en daar zit het tijdsverlies in deze niet in....
Okee, wilde alleen uitsluiten dat het om de 1 of andere vage reden niet aan je sql prog zelf lag.

Test je het trouwens lokaal allemaal?

[ Bericht 3% gewijzigd door Purplesparks op 12-07-2013 11:49:14 ]
Touching from a distance ~
  vrijdag 12 juli 2013 @ 13:04:15 #95
187069 slacker_nl
Sicko pur sang
pi_128867993
Hoe test je het eigenlijk, ben je de query via php aan het doen of die je het in een sql prompt?
In theory there is no difference between theory and practice. In practice there is.
pi_128868219
Zowel lokaal als online test ik dit, aangezien mijn lokale test omgeving maar uit zo'n 5m regels bestaat... maar goed, het is een laptop en de online server heeft nogal wat meer power en daar is het zelfs sloom :+

Query test ik via phpmyadmin, domweg omdat het gemakkelijk is! ;)
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  vrijdag 12 juli 2013 @ 13:55:34 #97
330295 Purplesparks
Lovercall baby
pi_128869760
quote:
14s.gif Op vrijdag 12 juli 2013 13:11 schreef Chandler het volgende:
Zowel lokaal als online test ik dit, aangezien mijn lokale test omgeving maar uit zo'n 5m regels bestaat... maar goed, het is een laptop en de online server heeft nogal wat meer power en daar is het zelfs sloom :+

Query test ik via phpmyadmin, domweg omdat het gemakkelijk is! ;)
Mijn stiefpa had een programma voor een bedrijf ontwikkeld, bij externe resultaten van bepaalde queries opvragen duurde het soms ook wel tot een minuut lang. Terwijl als hij het daar ter plekke testte een seconde of nog minder. Weet niet exact waar het aanlag maar hij heeft het opgelost. Hij maakte trouwens gebruik van delphi pascal in combinatie met een sql variant.
Touching from a distance ~
pi_128869951
quote:
0s.gif Op vrijdag 12 juli 2013 11:35 schreef Chandler het volgende:
Ja, en het rare is dat er geen filesort gebruikt wordt, dus het orderen gebeurd toch echt wel in het geheugen (als ik check met explain). Dacht zelf ook dat ik de indexes goed had en dat blijkt wel, maar het vervelende blijft dat ik per query met order by een kleine 1000x zolang bezig ben...

Maar hebben jullie tips? oh en de beperkte set van 17m rows zijn in dit geval zo'n 0,5m rows :@

@zoom:

Zonder order by
1 SIMPLE spider ref project_id_2,project_id project_id 9 const,const 536370

Met order by
1 SIMPLE spider index project_id_2,project_id failed 1 NULL 39 Using where
En wat doet een index op je WHERE clause én ORDER BY field(s)?

MySQL Performance Blog: ORDER BY … LIMIT Performance Optimization
MySQL Reference Manual: ORDER BY Optimization
pi_128907578
Ik heb het doorgelezen en ga het nog eens doorlezen want ben niet echt heel veel wijzer geworden dan dat ik al was :+ maar goed, in mijn geval zal ik het ws 3x moeten lezen :X
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  maandag 15 juli 2013 @ 11:29:04 #100
187069 slacker_nl
Sicko pur sang
pi_128965264
FF crossposten: http://nedbatchelder.com/text/unipain.html
In theory there is no difference between theory and practice. In practice there is.
actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
[PHP/(My)SQL] voor dummies #110
Index

» digital corner

» development

Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')