SearchEngines.bg

Това е примерно съобщение за гост. Регистрирайте безплатен акаунт днес, за да станете потребител на SearchEngines.bg! След като влезете, ще можете да участвате в този сайт, като добавите свои собствени теми и публикации, както и да се свържете с други членове чрез вашата лична входяща кутия! Благодарим ви!

Оптимизация на база данни

retro

New member
Става дума за база данни с около 22 000 записа в нея. Базата няма индекси, и търсенето на запис отнема около 10 сек. Освен това браузването на сайта е също много бавно, независимо дали се използва търсачката или не.

Днес след неколкократно предупреждение, хоста блокира достъпа до базата, поради многократно и сериозно превишаване на лимита от 25 % процесорно време.

Бихте ли дали пример, как да сложа индекси на базата, така, че малко да се облекчи този проблем?

Ето извадка от и-мейла от хоста, който показва какво се случва:

CPU_TIME:487 table_rows_read:145631995 SELECTS:1247 ROWS_UPDATED:0 ROWS_FETCHED:0 BUSY_TIME:523 BYTES_SENT:28935207 BYTES_RECEIVED:1357411


Top table row reads:
DB_USER: obqbi_j15 -- TOTAL_CONNECTIONS: 508 -- CPU_TIME: 487 -- TABLE_ROW_READS: 145631995 -- SELECT_COMMANDS: 1247 -- UPATE_COMMANDS: 1079 -- BUSY_TIME: 523 -- BYTES_SENT: 28935207 -- BYTES_RECEIVED: 1357411



Top CPU TIME:
DB_USER: obqbi_j15 -- TOTAL_CONNECTIONS: 508 -- CPU_TIME: 487 -- TABLE_ROW_READS: 145631995 -- SELECT_COMMANDS: 1247 -- UPATE_COMMANDS: 1079 -- BUSY_TIME: -- BYTES_SENT: 28935207 -- BYTES_RECEIVED: 1357411



obqbi 2138 8.3 0.1 43516 20384 ? SN 00:56 0:00 /usr/bin/php /home/obqbi/public_html/index.php
obqbi 2232 25.0 0.0 0 0 ? ZN 00:56 0:00
PHP:
 <defunct> 
obqbi 2234 26.0 0.0 0 0 ? ZN 00:56 0:00 [php] <defunct> 
root 2282 0.0 0.0 2548 860 ? SN 00:56 0:00 sh -c ps aux | grep obqbi 
root 2284 0.0 0.0 1988 420 ? SN 00:56 0:00 grep obqbi 

Tue Jul 26 00:56:51 CDT 2011 
Running Processes: 
obqbi 2138 8.3 0.1 43516 20384 ? SN 00:56 0:00 /usr/bin/php /home/obqbi/public_html/index.php 
obqbi 2232 25.0 0.0 0 0 ? ZN 00:56 0:00 [php] <defunct> 
obqbi 2234 26.0 0.0 0 0 ? ZN 00:56 0:00 [php] <defunct> 
obqbi 2292 0.0 0.0 22008 2348 ? RN 00:56 0:00 /usr/bin/php /home/obqbi/public_html/index.php 

Running Queries: 
*************************** 1. row *************************** 
 USER: obqbi_j15 
 DB: obqbi_j15 
 STATE: Copying to tmp table 
 TIME: 1 
COMMAND: Query 
 INFO: SELECT a.*, p.name as parent, p.id as parentid, c.name as cat, c.id as catid, u.username as user FROM jos_adsmanager_ads as a LEFT JOIN jos_adsmanager_adcat as adcat ON adcat.adid = a.id LEFT JOIN jos_users as u ON a.userid = u.id LEFT JOIN jos_adsmanager_categories as c ON adcat.catid = c.id LEFT JOIN jos_adsmanager_categories as p ON c.parent = p.id WHERE 1 AND (a.ad_headline LIKE '%?????????%' OR a.ad_text LIKE '%?????????%' OR a.ad_headline LIKE '%ekskurziq%' OR a.ad_text LIKE '%ekskurziq%' OR a.ad_headline LIKE '%?????????%' OR a.ad_text LIKE '%?????????%') AND a.published = 1 and c.published = 1 GROUP BY a.id ORDER BY `a`.`t_stars` DESC, a.date_created DESC ,a.id DESC LIMIT 400, 10 
*************************** 2. row *************************** 
 USER: obqbi_j15 
 DB: obqbi_j15 
 STATE: 
 TIME: 3 
COMMAND: Sleep 
 INFO: NULL
 
Последно редактирано:
Re: Оптимизация на база данни

наистина са малко записите, но зависи каква е структурата и заявките.
От хостинга дадоха ли ти някаква идея кои заявки са ти бавни?

Не е лошо да видим някоя друга заявка.

По - принцип трябва да се внимава със слагането на индекси защото в някой случаи могат да забавят нещата. Обикновенно като правило индекс се слага на полета в WHERE клаузата по които филтрираш. Препоръчително е тези полета да има цифрови стойности. Но всичко много варира. Така че се опитай да разбереш коя заявка бави да видим какво може да се направи.

Поздрави
 
Re: Оптимизация на база данни

Не, това което ми пратиха са горе долу общи насоки за възможните причини за проблема:

This message is to advise you of a temporary block placed on your database. The database was found to be consuming an inordinate amount of processor time, to the point of degrading overall system performance. While we do limit each account to no more than 25% of a system's CPU in our terms of service, we do not actively disable accounts until they greatly exceed that number, which is what happened in this case. Requests to this database may become degraded by limiting the maximum number of queries or connections for a limited amount of time, or if there are sustained issues, ultimately we may be forced to block access to this database until the issue has been resolved.

Resolving this situation may be as simple as adding additional indexes to your database, optimizing the queries used, or something equally easy. If not, it may simply be a matter of moving this database to dedicated services, as it may have outgrown a shared environment.

If you believe you have a solution to this overuse, we are happy to discuss the situation with you and possibly reinstate the database on the server. Otherwise, we will be happy to assist you with the upgrade process if a dedicated server is the most appropriate solution. Thank you, and we look forward to hearing from you shortly.

~~~
Excessive MySQL activity is caused by (a) a long-running process that locks a table, causing other queries to back up, (b) a query that is not optimized ][example: select all from ... and involving a large or complex query], (c) huge table copies/maintenance during peak hours.

NOTE:, the following are just possible fixes or suggestions, and are not endorsed or supported by HostGator. They are included in the hope that they may apply to your situation, and/or help you reduce the amount of resources your SQL queries consume. As always, it's best to backup any data before making any changes or adjustments.

First and foremost, you may need to optimize your tables. The frequency depends on the size and usage of the database, but most databases would benefit from doing something like this on a yearly basis: a) Enter your phpMyAdmin/MySQL control panel. Click on the database (not the table, the database name), and on the right hand column your tables should be listed. Scroll down till you see the .Check all. link. Click on that link, make sure all database tables are checked and then from the drop-down next to it, and carefully select .Optimize table..

Additionally, adding indexes to your table(s) may improve performance. If you're not sure what you're doing, it's best not to modify any table; caution is recommended. There are various articles (http://www.developer.com/db/article.php/3667831/Four-Ways-to-Optimize-Your-MySQL-Database.htm and http://www.databasejournal.com/feat...2791/Optimizing-MySQL-Queries-and-Indexes.htm). It may be best to Google for something like [Your Software Name] MySQL indexes for suggestions.

If you reply back to this with your IP address (http://www.hostgator.com/ip.shtml) we will be more than happy to go ahead enable HTTP access for you, so that you can safely work on the script without it causing further issues. Please let us know how you would like to proceed.


-------------------------------------------------------------------------
Как да пусна някоя заявка, за да я постна тук после?
 
Последно редактирано:
Re: Оптимизация на база данни

мале мале използваш всичките възможни неща дето бавят заявката :)

сега отиди в phpMyAdmin и я пусни така да видим какво показва :

Код:
EXPLAIN SELECT a.*, p.name as parent, p.id as parentid, c.name as cat, c.id as catid, u.username as user FROM jos_adsmanager_ads as a LEFT JOIN jos_adsmanager_adcat as adcat ON adcat.adid = a.id LEFT JOIN jos_users as u ON a.userid = u.id LEFT JOIN jos_adsmanager_categories as c ON adcat.catid = c.id LEFT JOIN jos_adsmanager_categories as p ON c.parent = p.id WHERE 1 AND (a.ad_headline LIKE '%%' OR a.ad_text LIKE '%%' OR a.ad_headline LIKE '%ekskurziq%' OR a.ad_text LIKE '%ekskurziq%' OR a.ad_headline LIKE '%%' OR a.ad_text LIKE '%%') AND a.published = 1 and c.published = 1 GROUP BY a.id ORDER BY `a`.`t_stars` DESC, a.date_created DESC ,a.id DESC LIMIT 400, 10
 
Re: Оптимизация на база данни

Резултата от заявката е следния:

SQL заявката беше изпълнена успешно

EXPLAIN SELECT a . * , p.name AS parent, p.id AS parentid, c.name AS cat, c.id AS catid, u.username AS user
FROM jos_adsmanager_ads AS a
LEFT JOIN jos_adsmanager_adcat AS adcat ON adcat.adid = a.id
LEFT JOIN jos_users AS u ON a.userid = u.id
LEFT JOIN jos_adsmanager_categories AS c ON adcat.catid = c.id
LEFT JOIN jos_adsmanager_categories AS p ON c.parent = p.id
WHERE 1
AND (
a.ad_headline LIKE '%%'
OR a.ad_text LIKE '%%'
OR a.ad_headline LIKE '%ekskurziq%'
OR a.ad_text LIKE '%ekskurziq%'
OR a.ad_headline LIKE '%%'
OR a.ad_text LIKE '%%'
)
AND a.published =1
AND c.published =1
GROUP BY a.id
ORDER BY `a`.`t_stars` DESC , a.date_created DESC , a.id DESC
LIMIT 400 , 10


id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE adcat index PRIMARY PRIMARY 8 NULL 22940 Using index; Using temporary; Using filesort
1 SIMPLE a eq_ref PRIMARY PRIMARY 4 obqbi_j15.adcat.adid 1 Using where
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 obqbi_j15.a.userid 1
1 SIMPLE c eq_ref PRIMARY PRIMARY 4 obqbi_j15.adcat.catid 1 Using where
1 SIMPLE p eq_ref PRIMARY PRIMARY 4 obqbi_j15.c.parent 1
 
Re: Оптимизация на база данни

Няколко коментара:

AND (
a.ad_headline LIKE '%%'
OR a.ad_text LIKE '%%'
OR a.ad_headline LIKE '%ekskurziq%'
OR a.ad_text LIKE '%ekskurziq%'
OR a.ad_headline LIKE '%%'
OR a.ad_text LIKE '%%'
)

a.ad_headline LIKE '%%' е винаги true, което обезсмисля този филтър. Иначе бих заложил на индекси по полетата за сортиране:

композитен (`a`.`t_stars` , a.date_created)

Пусни пак същия explain след това за сравнение.
 
Re: Оптимизация на база данни

еми така като гледам всичко си е наред със заявката (смисел има си индекси където трябва).

Като я пуснеш без EXPLAIN за колко време се изпълнява?
 
Re: Оптимизация на база данни

@bubatalazi

"a.ad_headline LIKE '%%' е винаги true, което обезсмисля този филтър. Иначе бих заложил на индекси по полетата за сортиране:

композитен (`a`.`t_stars` , a.date_created)

Пусни пак същия explain след това за сравнение."

КАК ДА СЛОЖА ИНДЕКСИ ПО ПОЛЕТАТА ЗА СОРТИРАНЕ?


@bobbydigital

Без EXPLAIN първоначално даде това като време:

Показване на записи 0 - 9 (10 Общо, Заявката отне 2.7812 секунди)

Веднага след това я пуснах повторно пак без EXPLAIN и ми даде това време:

Показване на записи 0 - 9 (10 Общо, Заявката отне 0.0002 секунди)

Очевидно второто време вече е нещо кеширано, а не изпълнено реално.

В резултата са маркирани с оранжево полетата ad_headline и ad_text

Това време от близо 3 секунди изглежда нереално малко, през сайта търсенето/браузването отнема около 4-5 сек до 10 сек.
 
Последно редактирано:
Re: Оптимизация на база данни

@bubatalazi от индексите според мен няма да има ефект, но за лайковете си прав.

@retro в phpmyadmin - отиваш на таблицата, избираш "structure" и най долу даваш add index.
 
Re: Оптимизация на база данни

Индекси по полетата за сортиране не помагат.

Пробвахте ли с mysqli?

Според мен цялото забавяне е от тези LIKE-ове. При тях индексите не важат, защото се изследва цялата стойност и е адски бавно.

Сега не ми се вниква в заявката, но ако не може да ги избегнете тези LIKE-ове, регулярните изрази са малко по-бързи за тази цел, колкото и да е нелогично, така че ги заменете с такива.
 
Последно редактирано:
Re: Оптимизация на база данни

@bobbydigital

за коя таблица е удачно според теб да се създадат индекси, още повече, че казваш, че няма да има ефект от тях?

Доколкото видях таблицата adsmanager_ads има индекс:

Данни 19,296.7 КБ
Индекс 202.0 КБ
Загубено място 7,380 байта
Ефективни 19,491.5 КБ
Общо 19,498.7 КБ

@cloxy

Напълно е възможно забавянето да е от тези LIKE-ове. Как можем да ги махнем от сорса и с какво да ги заменим?
 
Re: Оптимизация на база данни

пробвай да ги конкатенираш полетата и да направиш LIKE на резултата - така ще е само един и предполагам, че ще е по-бързо

CONCAT(`field1`, `field2`....) LIKE "%ekskurziq%"
 
Re: Оптимизация на база данни

От хоста са направили задълбочен анализ на проблема и получих това по и-мейл току що, не вярвах, че са такива кучета тия от HostGator :)


Greetings,

Thank you for your patience. Upon reviewing the MySQL activities for this account we have discovered a number of issues that prevent, or ultimately degrade, any effective MySQL index. It appears that you are operating an ad service via a Joomla component/plugin/module and this plugin is inefficient in design. This plugin appears to hold caching mechanisms in its code base but it not using the caching mechanisms its fullest potential. Additionally, the SQL queries associated with this plugin are the most offending, in regards to resource use. The queries typically consist of multiple joins and full table reads which inherently consume resources. I have documented two additional issues within the queries themselves below for your reference. If you or your programmer are responsible for the code base used by this program I would recommend the following: 1) Split the major statements (specifically SQL queries using JOIN's) out to single, simple, select statement! s 2) cache the result of each query for an appropriate time span to either disk or memcache 3) Review Issue #2 documented below. If you are not responsible for this component I would have to recommend that you either 1) investigate other mechanisms to produce the ad system you desire (Google Adsense?) 2) upgrade to a VPS/dedicated server and make the appropriate changes to the timeout of SQL queries appropriately. The latter option would be the easiest as it would allow for a simple migration that could be handled by our transfers/sales department and also provide insurance that our SQL monitoring service does not implement restrictions on this account in the future.



Issues regarding the queries themselves:
Issue #1
Comparison functions for the 'adcat.adid' and 'adcat.catid' cannot be improved within this query due to the comparison style. I would recommend splitting up this query completly and build the associatations from cache within PHP. This will reduce the MySQL load per query and increase performance is the data needed to build the associatations could be cached on disk or in a separate cache table.

Issue #2
From the first query: """ WHERE 1 AND (a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%') """
There appears to be an issue with the query logic used in this query (repetitive 'LIKE' statements). Please have your developer investigate the use case of this query to determine a more suitable approach.


mysql> explain SELECT a.*, p.name as parent, p.id as parentid, c.name as cat, c.id as catid, u.username as user FROM jos_adsmanager_ads as a LEFT JOIN jos_adsmanager_adcat as adcat ON adcat.adid = a.id LEFT JOIN jos_users as u ON a.userid = u.id LEFT JOIN jos_adsmanager_categories as c ON adcat.catid = c.id LEFT JOIN jos_adsmanager_categories as p ON c.parent = p.id WHERE 1 AND (a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%') AND a.published = 1 and c.published = 1 GROUP BY a.id ORDER BY `a`.`t_stars` DESC, a.date_created DESC ,a.id DESC LIMIT 0, 10;
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
| 1 | SIMPLE | adcat | index | PRIMARY | PRIMARY | 8 | NULL | 22043 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | a | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.adcat.adid | 1 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.a.userid | 1 | |
| 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.adcat.catid | 1 | Using where |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.c.parent | 1 | |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
5 rows in set (0.00 sec)

mysql> explain SELECT a.id,a.views, a.ad_headline, a.category, a.date_created,p.id as parentid,p.name as parent,c.id as catid, c.name as cat FROM jos_adsmanager_ads as a LEFT JOIN jos_adsmanager_adcat as adcat ON adcat.adid = a.id LEFT JOIN jos_users as u ON a.userid = u.id LEFT JOIN jos_adsmanager_categories as c ON adcat.catid = c.id LEFT JOIN jos_adsmanager_categories as p ON c.parent = p.id WHERE c.published = 1 and a.published = 1 GROUP BY a.id ORDER BY a.date_created DESC ,a.id DESC LIMIT 0, 3;
Current database: obqbi_j15

+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
| 1 | SIMPLE | adcat | index | PRIMARY | PRIMARY | 8 | NULL | 22043 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | a | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.adcat.adid | 1 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.a.userid | 1 | Using index |
| 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.adcat.catid | 1 | Using where |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 4 | obqbi_j15.c.parent | 1 | |
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+-------+----------------------------------------------+
5 rows in set (0.00 sec)

mysql> explain SELECT DISTINCT a.id FROM jos_adsmanager_ads as a LEFT JOIN jos_adsmanager_adcat as adcat ON a.id = adcat.adid WHERE 1 AND (a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%' OR a.ad_headline LIKE '%404.%' OR a.ad_text LIKE '%404.%') AND a.published = 1;
Current database: obqbi_j15

+----+-------------+-------+------+---------------+---------+---------+---------------------+-------+------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+---------+---------+---------------------+-------+------------------------------+
| 1 | SIMPLE | a | ALL | NULL | NULL | NULL | NULL | 21997 | Using where; Using temporary |
| 1 | SIMPLE | adcat | ref | PRIMARY | PRIMARY | 4 | obqbi_j15.a.id | 1 | Using index; Distinct |
+----+-------------+-------+------+---------------+---------+---------+---------------------+-------+------------------------------+
2 rows in set (0.00 sec)

mysql> show indexes from jos_adsmanager_adcat;
+----------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+----------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| jos_adsmanager_adcat | 0 | PRIMARY | 1 | adid | A | 22043 | NULL | NULL | | BTREE | |
| jos_adsmanager_adcat | 0 | PRIMARY | 2 | catid | A | 22043 | NULL | NULL | | BTREE | |
+----------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
2 rows in set (0.00 sec)

mysql> show indexes from jos_adsmanager_ads ;
Current database: obqbi_j15
+--------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+--------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| jos_adsmanager_ads | 0 | PRIMARY | 1 | id | A | 21997 | NULL | NULL | | BTREE | |
+--------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.00 sec)
 
Re: Оптимизация на база данни

Виж ми поста над твоя, защото сме ги писали едновременно и може да си го пропуснал
 
Re: Оптимизация на база данни

Пробвах с това

CONCAT(`ad_headline`, `ad_text`) LIKE "%ekskurziq%"

и това

CONCAT(`a.ad_headline`, `a.ad_text`) LIKE "%ekskurziq%"

и при двата случая ми даде грешка:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONCAT(`ad_headline`, `ad_text`) LIKE "%ekskurziq%"' at line 1

@cloxy

какво имаше предвид когато каза да пробвам с използване на mysqli?
 
Последно редактирано:
Re: Оптимизация на база данни

Майко мила....

С една дума ДЕНОРМАЛИЗАЦИЯ.

cloxy дали пък база, която се лоадва при всяко зареждане е по-добра от тази, която седи в паметта? Особено пък такава, която се обхожда цялата?;)
Хубаво си фен на това подобие на база, ама времето на бази данни тип flat file им мина много отдавна да се ползват за нещо повече от това да държат конфигурационен файл.
 
Re: Оптимизация на база данни

Майко мила....

С една дума ДЕНОРМАЛИЗАЦИЯ.

cloxy дали пък база, която се лоадва при всяко зареждане е по-добра от тази, която седи в паметта? Особено пък такава, която се обхожда цялата?
Хубаво си фен на това подобие на база, ама времето на бази данни тип flat file им мина много отдавна да се ползват за нещо повече от това да държат конфигурационен файл.

Без да се заяждам, искам да кажа, че не си в час.
1-во : казва се НОРМАЛИЗАЦИЯ, в случай може да искара полетата по които търси с LIKE в друга таблица, но това няма да помогне на заявката, а напротив ще има още един LEFT JOIN
2-ро : mysqli е адаптор за работа с mysql на PHP какви flat файлове те гонят. В този ред на мисли според теб mysql в какви файлове си пази базите?

@retro -

1. пробвай да пуснеш заявката без GROUP защото тука нещо ми намирисва не би трябвало да го има този GROUP, виж данните дали се повтарят, ако не се повтарят и времето намалява ок

2. тествай ORDER клаузата само ей така :
ORDER BY `a`.`t_stars` DESC, a.date_created DESC
без a.id DESC

3. пробвай да видиш без LIKE за колко време се изпълнява, помисли да сложиш ограничение на дължината на търсената дума примерно 3+ символа
 
Re: Оптимизация на база данни

bobbydigital, дали пък наистина имах предвид "нормализация"? ;)

Не съм споменавал думата join, нито съм препоръчал използването му. Заключението ти е погрешно. При големи бази (макар, че тази от 22к реда си е смешно малка) използването на join си е чиста пробра самоубийство.
 
Re: Оптимизация на база данни

retro ако дадеш dump на jos_adsmanager_ads, jos_adsmanager_adcat, jos_adsmanager_categories, jos_adsmanager_categories
доста ще улесниш нещата.
 

Горе