Mysql
 sql >> база данни >  >> RDS >> Mysql

От гледна точка на производителността, колко ефективно е използването на временна таблица на MySQL за силно използвана функция на уебсайт?

Това, което посочихте, е напълно правилно, временната таблица ще бъде видима само за текущия потребител/връзка. Все пак има някои режийни и някои други проблеми като:

  • За всяко от хилядите търсения, които ще създадете и попълните тази таблица (и ще я пуснете по-късно) – не за потребител, за търсене. Тъй като всяко търсене най-вероятно ще изпълни повторно скрипта, а „на сесия“ не означава PHP сесия – това означава сесия на база данни (отворена връзка).
  • Ще ви трябва CREATE TEMPORARY TABLES привилегия, която можете нямам.
  • Все пак тази таблица наистина трябва да има тип MEMORY, който краде вашата RAM памет повече, отколкото изглежда. Тъй като дори с VARCHAR, таблиците MEMORY използват съхранение на редове с фиксирана дължина.
  • Ако по-късно евристиката ви трябва да се обърне към тази таблица два пъти (като SELECT xyz FROM patternmatch AS pm1, patternmatch AS pm2 ... ) - това не е възможно с таблици MEMORY.

След това ще бъде по-лесно за вас - а също и за базата данни - да добавите LIKE '%xyz%' директно към вашите images таблици WHERE клауза. Той ще направи същото, без да създава излишни разходи за създаване на TEMP TABLE и присъединяване към нея.

Във всеки случай - независимо по кой път тръгнете - това WHERE ще бъде ужасно бавно. Дори ако добавите индекс към images.name най-вероятно ще ви трябва LIKE '%xyz%' вместо LIKE 'xyz%' , така че индексът няма да се използва.

Не. :)

Алтернативни опции

MySQL има вграден Fulltext-Search (от 5.6 също за InnoDB), който дори може да ви даде тази оценка:силно препоръчвам да го прочетете и да опитате. Можете да сте сигурни, че базата данни знае по-добре от вас как да прави това търсене ефективно.

Ако ще използвате MyISAM вместо InnoDB, имайте предвид често пренебрегваното ограничение, че FULLTEXT търсенията връщат нещо само ако броят на резултатите е по-малък от 50% от общия ред на таблицата.

Други неща, които може да искате да разгледате, са например Solr (Хубаво въведение, прочетено в самата тема, би било началото на http://en.wikipedia.org/wiki/Apache_Solr ). Ние го използваме в нашата компания и върши страхотна работа, но изисква известно обучение.

Резюме

Решението на самия ви текущ проблем (търсене) е да използвате възможностите на FULLTEXT.

За да ви дадем цифра, 10 000 обаждания в секунда вече не са „тривиални“ – със стотици хиляди търсения в секунда проблемите с производителността, които ще срещнете, са навсякъде във вашата настройка. Ще ви трябват няколко сървъра, балансиране на натоварването и много други невероятни технически глупости. И едно от това ще бъде например Solr;)



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL CONCAT връща NULL, ако някое поле съдържа NULL

  2. Крайна стъпка на заявката е много дълга в произволни моменти

  3. Как да стартирате RAW SQL заявка в PhalconPHP

  4. Това защитен метод ли е за вмъкване на данни от формуляра в MySQL база данни?

  5. ИНДИЯ, STD Code Finder Script в PHP, MYSQL, JQUERY