[MySQL] Domein tabel

woensdag 25 juni 2008 18:20

And the cow said: Helloooooow?

Topicstarter

Hmmmzz... dat klinkt wel koel

Betekend dus dat de query min of meer hetzelfde blijft, maar dat de string omgedraaidt wordt:

SQL:

SELECT
      `domain`.`siteId`
FROM
        `domain`
WHERE
        `domain`.`name_rev` LIKE 'ln.tset.www%'
ORDER BY LENGTH(`domain`.`name`) DESC;

Vraag die dan overblijft (of juist ontstaat) moet de '.' er dan nog achteraan? (in de LIKE én in de `domain`.`name`)

of begrijp ik het niet?

Gekkie is a proud member of TheBenny!

Acties:

bigbeng

Ja, want je wil toch subdomeinen vinden? Anders vindt je bij het zoeken op tweakers.net ook wij.zijncooletweakers.net en dat is natuurlijk iets anders

woensdag 25 juni 2008 18:28

Acties:

vrijdag 27 juni 2008 10:12

And the cow said: Helloooooow?

Topicstarter

Dus de truuc is dan al in mn reversed column ook de extra '.' meenemen en in mn like deze er gewoon in zetten met mn PHP

Prima prima!

Gekkie is a proud member of TheBenny!

Acties:

vrijdag 27 juni 2008 11:10

And the cow said: Helloooooow?

Topicstarter

Ik krijg het maar niet goed voor elkaar... Wat doe ik fout:
- ik heb de tabel aangepast zodat er nu een extra kolom 'name_rev' erbij is gekomen die de naam reversed + een extra '.' bevat: "test.nl" wordt "ln.tset."
- ik heb de where in de query aangepast naar "domain`.`name_rev` LIKE 'ln.tset.%'"

maar ik krijg veel meer resultaten dan volgens de eerdere query... ? Als ik voorheen met 'test.nl' inzette kreeg ik alleen 'test.nl' terug. Nu met de reversed oplossing krijg ik bovenaan de meest uitgebreide subdomein specificatie terug... (bijvoorbeeld dit.is.nu.een.test.nl ) wat in dit geval natuurlijk niet de bedoeling is doordat ik op test.nl uit had moeten komen...

Wat doe ik fout?

[ na wat meer testen]

ik heb nu de volgende query:

SQL:

EXPLAIN SELECT  `domain` . *
FROM `domain`
WHERE 'ln.test.' LIKE CONCAT( `domain`.`name_rev` , '%' )
ORDER BY LENGTH( `domain`.`name` ) DESC ;

Deze geeft hetzelfde resultaat als de eerdere query, maar gebruikt ook geen index op 'name_rev'... In andere woorden: hier bereik ik hetzelfde resultaat én dus ook hetzelfde probleem mee: geen gebruik van indexen...

ik herhaal mezelf dus maar even: wat doe ik dan fout?

[ Voor 26% gewijzigd door _Gekkie_ op 27-06-2008 10:31 . Reden: extra testjes ]

Gekkie is a proud member of TheBenny!

Acties:

vrijdag 27 juni 2008 11:15

Zet die procent nou gewoon dmv code zodat je er in je query eenvoudigweg `domain`.`name_rev` LIKE 'ln.test.%' staat. Omdat er dan geen functie over die kolom gegooid wordt is de index tenminste wel bruikbaar. Sowieso had je wel op je klompen aan kunnen voelen dat die concat() nogal suf is.

En als je de kortste domeinnaam terug wel krijgen moet je uiteraard in ASCending order sorteren.

Ook hier geldt dat je nu een functie gebruikt, waardoor deze order by clause relatief duur zal zijn (wellicht filesort zichtbaar bij explain van query).

[ Voor 30% gewijzigd door Voutloos op 27-06-2008 11:12 ]

{signature}

Acties:

vrijdag 27 juni 2008 11:21

And the cow said: Helloooooow?

Topicstarter

Dat had ik ook wel begrepen, maar nogmaals, deze twee queries leveren niet hetzelfde resultaat:

SQL:

SELECT
      `domain`.*
FROM
        `domain`
WHERE
        '.tset.nl' LIKE CONCAT('%.', `domain`.`name`)
ORDER BY LENGTH(`domain`.`name`) DESC;

SQL:

SELECT
      `domain`.*
FROM
        `domain`
WHERE
        `domain`.`name_rev` LIKE 'ln.tset.%'
ORDER BY LENGTH(`domain`.`name`) DESC;

Die tweede geeft me namelijk _alle_ resultaten waar test.nl in staat dus ook alle eventuele subdomeinen e.d. .. stel dat er een 'dit.is.een.test.nl' was vind ik die met de 'test.nl' vergelijking... échter in de eerste query vind ik de juiste... namelijk 'test.nl'...

[edit]
sterker nog: beide queries hebben nu dezelfde explain, waar de eerste maar 1 resultaat geeft, en de tweede alle waar 'test.nl' voorkomt (dus ook 'test.nu.is.er.weereen.test.nl') én ze gebruiken beide géén index... ?

[ Voor 13% gewijzigd door _Gekkie_ op 27-06-2008 11:19 ]

Gekkie is a proud member of TheBenny!

Acties:

vrijdag 27 juni 2008 11:25

Ook in de 1e query kan je die wildcard op een fatsoenlijke plek neerzetten en zijn het toch wel heel eenvoudige queries die je echt zelf moet kunnen debuggen. Op het moment dat beide kolommen netjes elkaars reverse zijn en de like clause ook netjes omgedraaid is is het gedrag uiteraard hetzelfde.

én ze gebruiken beide géén index... ?

Is er wel een index?

En soms wordt een index alsnog genegeerd, afhankelijk van cardinaliteit etc.

Post een je complete tabel structuur en explain.

[ Voor 24% gewijzigd door Voutloos op 27-06-2008 11:24 ]

{signature}

Acties:

vrijdag 27 juni 2008 11:34

And the cow said: Helloooooow?

Topicstarter

Dat ik iets niet goed doe, dat begrijp ik ook wel... in inderdaad '- x - = +'... Zover kom ik ook nog... Maar wat het dan wel moet zijn weet ik niet... Dat is juist mijn vraag

De complete structuur:

SQL:

CREATE TABLE `domain` (
  `id` bigint(20) NOT NULL default '0',
  `name` varchar(255) NOT NULL,
  `name_rev` varchar(255) NOT NULL,
  `siteId` bigint(20) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `siteId` (`siteId`),
   KEY `name_rev` (`name_rev`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

query:

SQL:

SELECT
      `domain`.*
FROM
        `domain`
WHERE
        `domain`.`name_rev` LIKE  'ln.tset.%'
ORDER BY LENGTH(`domain`.`name`) DESC;

levert de volgende explain:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE domain range name_rev name_rev 767 NULL 1 Using where; Using filesort

Problemen met deze oplossing:
- als ik volgens de originele query zoek op een domein die er níet specifiek instaat: 'testje.test.nl' maar 'test.nl' staat er wel in, vind ik test.nl... bij de tweede vind ik niets...
- ze gebruiken beide (originele en nieuwe oplossing) geen index (de explain is voor beide hetzelfde)

[ Voor 74% gewijzigd door _Gekkie_ op 27-06-2008 11:31 ]

Gekkie is a proud member of TheBenny!

Acties:

vrijdag 27 juni 2008 11:45

De key kolom van je explain is gewoon gevuld, dus er wordt een index gebruikt.

Waarom de filesort nodig is heb ik reeds gezegd. 'using index' in de extra kolom, als je daarnaar op zoek wat is iets anders, dan is namelijk een covering index.

Oftewel: order by kan beter maar verder qua optimalisatie geen echte problemen meer.

{signature}

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Je zou eventueel (nogal dubbelop) de lengte nog in een extra field kunnen toevoegen, scheelt je ook weer een LENGTH call.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

vrijdag 27 juni 2008 11:49

Acties:

vrijdag 27 juni 2008 11:53

And the cow said: Helloooooow?

Topicstarter

Stoem: zodra ik een niet vermeld domeinnaam gebruik (zoals 'example.org') gebruikt ie wel de index, maar een veelvoorkomende naam gebruikt ie geen index...

Wel begrijp ik dat er dus eigenlijk weinig te optimaliseren valt (om het resultaat hetzelfde te houden) Ik moet en zal de where clause hetzelfde moeten laten ... Namelijk de opgevraagde domeinnaam 'test.nl' als basis gebruiken op een wildcard table waarde... :

SQL:

1	... WHERE 'ln.tset.' LIKE CONCAT(`domain`.`name_rev`, '%')

Of de '%' dan aan het einde of aan het begin staat, zou niet uit moeten maken... het is nu alleen de '.' die ik in de concat weg kan laten...

en dus kom ik terug aan het begin:
ik kan dus de originele oplossing laten staan, blijkbaar kan het niet veel beter... ?

Gekkie is a proud member of TheBenny!

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

_Gekkie_ schreef op vrijdag 27 juni 2008 @ 11:49:
Of de '%' dan aan het einde of aan het begin staat, zou niet uit moeten maken...

Tuurlijk wel

Wat doe je liever? Zoeken in het telefoonboek naar alle namen die eindigen op %dijk of die beginnen met dijk%?
In het geval van %dijk kun je geen index gebruiken en zul je een full-telefoonboek-scan (full table scan) moeten doen en in het geval van dijk% kun je gewoon je index gebruiken (vingertje bij de d - i - j - k en vanaf daar verder lezen).

[ Voor 27% gewijzigd door RobIII op 27-06-2008 11:55 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

vrijdag 27 juni 2008 11:55

Acties:

vrijdag 27 juni 2008 12:10

Leg het probleem eens fatsoenlijk uit, want qua logica moet er gewoon, ongeacht al dan niet reversed opslag van dat veld, vrij simpel uit te komen zijn. Als je gewoon weet welk deel je met een wildcard wil matchen en of je wel of niet dat puntje wil afdwingen is dit verder echt geen rocket science.

{signature}

Acties:

dinsdag 9 september 2008 14:39

And the cow said: Helloooooow?

Topicstarter

Het doel van het systeem is de apache directive '*.domeinnaam' oplossen ... Dat is het belangrijkste.
Alle domeinnamen staan in 1 tabel:

SQL:

CREATE TABLE `domain` (
  `id` bigint(20) NOT NULL default '0',
  `name` varchar(255) NOT NULL,
  `siteId` bigint(20) NOT NULL default '0',
  `mailDomainId` int(11) NOT NULL,
  `_rev` varchar(255) NOT NULL,
  `_length` tinyint(4) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `siteId` (`siteId`),
  KEY `_length` (`_length`),
  KEY `_rev` (`_rev`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Ik gebruik een PHP script als bootstrap om te achterhalen welke site ik moet tonen:

SQL:

SELECT
    `domain`.`siteId` as `siteId`,
    `domain`.`id` as `domainId`
FROM
    `domain`
WHERE ('[gezochte domeinnaam]' LIKE CONCAT('%.', `domain`.`name`))
ORDER BY `domain`.`_length` DESC

Ik heb de volgende domeinen in mn tabel:
- test.nl (siteId 1)
- www.test.nl (siteId 1)
- nu.test.nl (siteId 2)
- nu.nl (siteId 3)
- test.tweakers.net (siteId 1)

SItuatieschetsen:
input | gewenst siteId
test.nl | 1
test.test.nl | 1
www2.test.nl | 1
nu.test.nl | 2
www.nu.nl | 3
www.tweakers.net | null *niet gevonden*
etc

Dat kan ik bereiken met de huidige query... (even de _length meegenomen)

Echter gebruikt die query niet (altijd?) de index op 'name'. En dus kan het nogal een onhandige query worden als deze _iedere_ hit op de webserver wordt uitgevoerd

De reallife situatie is alsvolgt:
- er staan 1435 domeinen in de tabel
- 1 op de 5 queries op een dedicated MySQL server is zo'n query als hierboven
- volgens mn slow-log analyser waar ik ook de non-indexed queries in opsla, zijn dit de statistieken voor die query:
Count : 15647 (19%)
Time : 88 s total, 0 s avg, 0 s to 1 s max
95% of Time : 0 s total, 0 s avg, 0 s to 0 s max
Lock Time : 11 s total, 0 s avg, 0 s to 1 s max
Rows sent : 1 avg, 0 to 3 max
Rows examined : 1605 avg, 1598 to 1644 max

Puur dus omdat het géén index kan gebruiken (behalve nu dan de _length maar die is minimaal natuurlijk)

Wat kan ik dus doen om het e.e.a. intelligenter te maken en inderdaad die vreemd uitziende CONCAT te vervangen door iets wat database vriendelijker is ...

Gekkie is a proud member of TheBenny!

Acties:

dinsdag 9 september 2008 15:09

And the cow said: Helloooooow?

Topicstarter

*schaamteloze schop*

Helaas blijft het probleem bestaan dat de queries niet te cachen is vanuit MySQL... Elke keer moet het systeem 1600+ (er zijn onderstussen weer domeinen bijgekomen) rijen bekijken volgens de EXPLAIN-op de query...

Niemand een slimme oplossing?

De geanalyseerde slow log:
Count : 21965 (27%)
Time : 140 s total, 0 s avg, 0 s to 1 s max
95% of Time : 0 s total, 0 s avg, 0 s to 0 s max
Lock Time : 11 s total, 0 s avg, 0 s to 1 s max
Rows sent : 1 avg, 0 to 3 max
Rows examined : 1653 avg, 1646 to 1659 max

SQL:

SELECT
     `domain`.`id` as `domainId`
FROM
    `site`,
    `domain`,
    `base` AS `domainBase`,
    `base` AS `siteBase`
WHERE
    (`site`.`id` = `siteBase`.`id`)
    AND (`siteBase`.`deleted` = 0)
    AND (`domain`.`id` = `domainBase`.`id`)
    AND (`domainBase`.`deleted` = 0)
    AND (`domain`.`siteId` = `site`.`id`)
    AND ('.www.example.com' LIKE CONCAT('%.', `domain`.`name`))
ORDER BY LENGTH(`domain`.`name`) DESC;

Gekkie is a proud member of TheBenny!

Acties:

dinsdag 9 september 2008 18:34

Heb je nou al eens een extra kolom met de reversed string geprobeerd, zodat de wildcard aan het eind staat?

{signature}

Acties:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

Zomaar een idee: maak twee extra tabellen:

domainEnds(domainEndId,domainEndString)
domainsForDomainEnd(domainEndId,domainLength,domainId)

Deze tabellen kun je aanmaken door sql-opdrachten te gebruiken met SUBSTRING_INDEX erin, totdat er geen nieuwe info meer is gevonden. Met een index op domainEndString en een gecombineerde op (domainEndId, domainLength) zal het zeer snel gaan denk ik zo... En de benodigde ruimte is erg klein met 1600 domeinen.

dinsdag 9 september 2008 20:10

Acties:

Creepy

Tactical Espionage Splatterer

Een like die begint met een %... zolang je dat blijft houden kan er geen index worden gebruikt. Nooit. .. Zoals al eerder is aangegeven: pas dat eens aan.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

dinsdag 9 september 2008 21:52

Acties:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

Creepy schreef op dinsdag 09 september 2008 @ 20:10:
Een like die begint met een %... zolang je dat blijft houden kan er geen index worden gebruikt. Nooit. ..

Ik vind hier iemand die toch hoopt dat de 'n' van nooit af gaat. (Of dit ziet als een dubbele ontkenning.

)

dinsdag 9 september 2008 23:12

Acties:

dinsdag 9 september 2008 23:49

And the cow said: Helloooooow?

Topicstarter

@voutloos: Dat leverde de verkeerde resultaten op... de like staat op de kolom, niet op de waarde...
@pedorus: die begrijp ik niet helemaal?
@Creepy: De %-wildcard móet juist op de tabel, niet op mn string...
@pedorus (2): Dat lijkt er inderdaad wel op, maar daar staat de wildcard ook op de string, niet op de kolom.. ?

Dit heeft allemaal te maken met wat er het beste matcht...
Ik zal morgen wel even met de blogposting van jcole.us aan de gang...
- twee kolommen toevoegen:
`_name` en `_length`
- triggers:

SQL:

CREATE TRIGGER domain_r_in
  BEFORE INSERT ON domain
  FOR EACH ROW
    SET NEW._name = REVERSE(CONCAT(".", NEW.name)), NEW._length = LENGTH(NEW.name);

CREATE TRIGGER domain_r_up
  BEFORE UPDATE ON domain
  FOR EACH ROW
    SET NEW._name = REVERSE(CONCAT(".", NEW.name)), NEW._length = LENGTH(NEW.name);

en als laatste de query aanpassen naar:

SQL:

SELECT 
     `domain`.`id` as `domainId` 
FROM 
    `site`, 
    `domain`, 
    `base` AS `domainBase`, 
    `base` AS `siteBase` 
WHERE 
    (`site`.`id` = `siteBase`.`id`) 
    AND (`siteBase`.`deleted` = 0) 
    AND (`domain`.`id` = `domainBase`.`id`) 
    AND (`domainBase`.`deleted` = 0) 
    AND (`domain`.`siteId` = `site`.`id`)
    AND REVERSE('.www.example.com') LIKE CONCAT(`domain`.`_name`, '%')
ORDER BY `domain`.`_length` DESC;

Maar schopt die concact nu niet alsnog alles in de war?
Ik ga het morgen proberen!

Gekkie is a proud member of TheBenny!

Acties:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

_Gekkie_ schreef op dinsdag 09 september 2008 @ 23:12:
@Creepy: De %-wildcard móet juist op de tabel, niet op mn string...

Aha, ik was even in de war gebracht door oa deze post...

Tsja, in dat geval zou ik gewoon een query maken van de vorm

SQL:

1	where name in ("iets.www.test.nl","www.test.nl","test.nl")

Ja, dat is niet mooi, maar volgens mij doet mysql niet aan indexen bij queries waar de kolom rechts van like staat...

woensdag 10 september 2008 09:31

Acties:

Creepy

Tactical Espionage Splatterer

Ok duidelijk, maar in het begin van je topic geef je aan wel de reverse te hebben gebruikt maar dat er dan nog steeds geen index wordt gebruikt (wat pedorus ook al aangeeft

). Misschien totaal overbodig maaruh: kan je je complete tabelstructuur (dus inclusief indexen) eens geven dan samen met de EXPLAIN die je hebt gedraait? Dat geeft ons wat meer inzicht.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

woensdag 10 september 2008 10:14

Acties:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

Probeer anders eens of MySQL wel een index kan gebruiken bij de vorm:

SQL:

1	where _name=left(reverse("www.test.nl"),length(_name))

Het probleem met like is dat er misschien in de kolom wel het teken '%' staat. Er moet daarom iedere keer weer een nieuw like-pattern gecompileerd worden, wat flink tijd zal kosten. Waarschijnlijk is het volgende al wat sneller dan like:

SQL:

1 2	where name=right("www.test.nl",length(name)) and (length(name)=length("www.test.nl") or substr(...)='.')

woensdag 10 september 2008 10:34

Acties:

woensdag 10 september 2008 15:32

Trivia kennis: LEFT() is in mysql _nooit_ beter dan een LIKE met een trailing wildcard.

En ja, LEFT() moet in een aantal gevallen goed te optimaliseren zijn, maar dat gebeurd gewoon niet.

{signature}

Acties:

woensdag 10 september 2008 16:15

And the cow said: Helloooooow?

Topicstarter

Kijk, ik wist wel dat ik niet achterlijk was...

Zoals gevraagd de structuur:

SQL:

CREATE TABLE IF NOT EXISTS `domain` (
  `id` bigint(20) NOT NULL default '0',
  `name` varchar(255) NOT NULL,
  `siteId` bigint(20) NOT NULL default '0',
  `mailDomainId` int(11) NOT NULL,
  `hasMail` tinyint(4) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `siteId` (`siteId`),
  KEY `mailDomainId` (`mailDomainId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

De query:

SQL:

SELECT
     `siteBase`.`show` as `show`,
     `site`.`id` as `siteId`,
     `domain`.`id` as `domainId`
FROM
    `site`,
    `domain`,
    `base` AS `domainBase`,
    `base` AS `siteBase`
WHERE
    (`site`.`id` = `siteBase`.`id`)
    AND (`siteBase`.`deleted` = 0)
    AND (`domain`.`id` = `domainBase`.`id`)
    AND (`domainBase`.`deleted` = 0)
    AND (`domain`.`siteId` = `site`.`id`)
    AND ('.www.example.com' LIKE CONCAT('%.', `domain`.`name`))
ORDER BY LENGTH(`domain`.`name`) DESC;

en de resultaten van de explain:

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	site	index	PRIMARY	siteId	4	NULL	85	Using index; Using temporary; Using filesort
1	SIMPLE	domain	ref	PRIMARY,siteId	siteId	8	site.id	1	Using where
1	SIMPLE	domainBase	eq_ref	PRIMARY,deleted	PRIMARY	4	domain.id	1	Using where
1	SIMPLE	siteBase	eq_ref	PRIMARY,deleted	PRIMARY	4	domain.siteId	1	Using where

Doordat de mysql interne optimzer weet dat er met domain zelf niets te halen valt is de join (en de explain dus) op site, niet op domain...

Ik ben het met jullie eens dat de _name en de _length voordeel zouden moeten hebben, iedere mysql-function in je query zou er een te veel kunnen zijn (ivm de QueryCache)...

Ik ben misschien wel aan het muggeziften, maar de situatie is: iedere hit op de webserver dóet deze query voor de opgevraagde hostnaam... dus hóe sneller de query, hoe sneller álle hits.. ;o)

(of moet ik gewoon afstappen van uberhaupt query-en en een ander caching mechanisme bouwen die nóg sneller is?)

Gekkie is a proud member of TheBenny!

Acties:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

_Gekkie_ schreef op woensdag 10 september 2008 @ 15:32:
Ik ben misschien wel aan het muggeziften, maar de situatie is: iedere hit op de webserver dóet deze query voor de opgevraagde hostnaam... dus hóe sneller de query, hoe sneller álle hits.. ;o)

(of moet ik gewoon afstappen van uberhaupt query-en en een ander caching mechanisme bouwen die nóg sneller is?)

6+ms onnodige vertraging bij iedere request is echt veel te veel als je het mij vraagt. Ik zou dan testen welke (die met in of right) het snelste is, en die kiezen. Voor caching zou ik eens kijken naar APC. Kijk verder voor MySQL eens naar "LIMIT 1" en SQL_NO_CACHE.

Verder gaat er iets mis in die query lijkt wel; volgens mij moet je even zorgen dat domain als eerste staat en als eerste doorzocht wordt. Daarnaast raad ik INNER JOIN aan.

woensdag 10 september 2008 17:23

Acties:

woensdag 10 september 2008 17:55

And the cow said: Helloooooow?

Topicstarter

de query duurt inderdaad 0.0059 sec... Maar een limit noch het juist uitzetten van de cache heeft daar effect op...

Overigens is APC wel leuk voor het cachen van PHP, maar zorgt er meteen ook voor dat apache het weer af en toe af moet laten weten... (en je daar dus weer oplossingen voor moet verzinnen)

De inner join is ook wel leuk, maar ook dat heeft hier niet zoveel zin ivm het feit dat de where het al 1 op 1 aan elkaar schakelt...

De query kan dus worden: (.0059sec)

SQL:

SELECT SQL_NO_CACHE
`siteBase`.`show`,
`siteBase`.`id` as `siteId`,
`domain`.`id` as `domainId`
FROM
`domain`
INNER JOIN `site` ON `site`.`id` = `domain`.`siteId`
INNER JOIN `base` AS `domainBase` ON `domainBase`.`id` = `domain`.`id` AND `domainBase`.`deleted` = 0
INNER JOIN `base` AS `siteBase` ON `siteBase`.`id` = `site`.`id` AND `siteBase`.`deleted` = 0
WHERE (".www.example.com" LIKE CONCAT('%.', `domain`.`name`))
ORDER BY LENGTH(`domain`.`name`) DESC
LIMIT 1

en met de _name en _length:

SQL:

SELECT SQL_NO_CACHE
`siteBase`.`show`,
`siteBase`.`id` as `siteId`,
`domain`.`id` as `domainId`
FROM
`domain`
INNER JOIN `site` ON `site`.`id` = `domain`.`siteId`
INNER JOIN `base` AS `domainBase` ON `domainBase`.`id` = `domain`.`id` AND `domainBase`.`deleted` = 0
INNER JOIN `base` AS `siteBase` ON `siteBase`.`id` = `site`.`id` AND `siteBase`.`deleted` = 0
WHERE "moc.elpmaxe.www." LIKE CONCAT(`domain`.`_name`,'%')
ORDER BY `domain`.`_length` DESC
LIMIT 1

Dan is de query 0.0027sec

Toch lijk ik niet onder die CONCAT() uit te kunnen komen ivm het feit dat "LIKE `domain`.`_name`%" niet mag...

Gekkie is a proud member of TheBenny!

Acties:

woensdag 10 september 2008 18:21

Deze join syntax is gewoon mooier, dan enkel ',' operators en zoeken naar join voorwaarden in de where clause.

De huidige query moet gewoon in de query cache kunnen komen hoor. Dus of de query cache staat uit (of demand), of de gebruikte tabellen worden steeds geupdate waardoor deze query uit cache geflushed wordt.

{signature}

Acties: