Det du angav är helt korrekt, den tillfälliga tabellen kommer endast att vara synlig för den aktuella användaren/anslutningen. Ändå finns det vissa overhead och några andra problem som:
- För var och en av de tusentals sökningar du ska skapa och fylla den tabellen (och släppa den senare) - inte per användare, per sökning. Eftersom varje sökning med största sannolikhet kommer att köra om skriptet, och "per session" betyder inte PHP-session - det betyder databassession (öppen anslutning).
- Du behöver
CREATE TEMPORARY TABLESprivilegium, vilket du kanske inte har. - Ändå borde den tabellen verkligen ha MEMORY-typ, som stjäl ditt RAM-minne mer än det ser ut som. Eftersom även med VARCHAR använder MEMORY-tabeller radlagring med fast längd.
- Om din heuristik senare behöver referera till den tabellen två gånger (som
SELECT xyz FROM patternmatch AS pm1, patternmatch AS pm2 ...) - detta är inte möjligt med MEMORY-tabeller.
Därefter skulle det vara lättare för dig - och även för databasen - att lägga till LIKE '%xyz%' direkt till dina images tabeller WHERE klausul. Det kommer att göra samma sak utan att behöva skapa en TEMP TABLE och gå med i den.
I alla fall - oavsett vilken väg du går - att WHERE kommer att gå fruktansvärt långsamt. Även om du lägger till ett index på images.name du kommer troligen att behöva LIKE '%xyz%' istället för LIKE 'xyz%' , så att indexet inte kommer att användas.
Nej. :)
Alternativa alternativ
MySQL har en inbyggd Fulltextsökning (sedan 5.6 även för InnoDB) som till och med kan ge dig det poängen:jag rekommenderar starkt att du läser och provar. Du kan vara säker på att databasen vet bättre än du hur man gör den sökningen på ett effektivt sätt.
Om du ska använda MyISAM istället för InnoDB, var medveten om den ofta förbisedda begränsningen att FULLTEXT-sökningar endast returnerar något om antalet resultat är mindre än 50 % av de totala tabellraderna.
Andra saker som du kanske vill titta på är till exempel Solr (trevlig introduktion att läsa om själva ämnet skulle vara början på http://en.wikipedia.org/wiki/Apache_Solr ). Vi använder det i vårt företag och det gör ett bra jobb, men det kräver ganska mycket lärande.
Sammanfattning
Lösningen på själva ditt nuvarande problem (sökningen) är att använda FULLTEXT-funktionerna.
För att ge dig en siffra är 10 000 samtal per sekund inte redan "trivialt" - med hundratusentals sökningar per sekund finns den typ av prestandaproblem du kommer att stöta på överallt i din installation. Du kommer att behöva ett par servrar, lastbalansering och massor av annat fantastiskt tekniskt skit. Och en av dessa blir till exempel Solr;)