Выемка результатов запроса mysql с минимальными затратами

F0x

Новичок
Выемка результатов запроса mysql с минимальными затратами

Подкиньте идеек, как отказаться от следующей схемы действий:

Вообразим таковое положение:
Есть две большие таблицы, содержащие каждая до 1 000 000 записей. Поиск инфо производится по ним обеим одновременно соединяя их в общем запросе функцией мускула UNION.

Этапы:
1) Производится подсчет полученных результатов двумя запросами: первый запрос подсчитывающий число результатов из первой, а второй из второй таблицы:

$a = mysql_query("SELECT COUNT(*) FROM a WHERE string LIKE %search string%");

$b = mysql_query("SELECT COUNT(*) FROM b WHERE string LIKE %search string%");

Для чего используются данные запросы: они ведут подсчет полученных результатов, записывая полученную инфо в статистику поиска, и что важно, дают возможность использовать полосу навигации страниц - поскольку найденное число результатов уже известно.

2) Собственно производится главный запрос с приминением UNION, объединяющий таблицы a и b и выводящий через цикл результаты поиска: while($RESULT = mysql_fetch_array($request))
{

}

Так вот посоветуйте, господа присяжные, как можно оптимизировать подобную схему из двух этапов на схему из одного, так таки число записей в таблицах не маленькое - время поиска инфо по данной схеме крайне неприемлемое и при наилучшем стечении превышает 20 секунд
 

Screjet

Новичок
Изучи FULLTEXT поиск.

Результаты подсчета числа результатов поиска сохраняй в какой-либо кеш-таблицы, или, включай кеширование запросов.
 

F0x

Новичок
Есесьно кеш есть - число полученных результатов кешируется во временной таблице и не подсчитывается при дальнейших запросах. Но это не помогает - запросы всегда разные.
При fulltext раздуется индекс, а скорость поиска еще более понизится
 

F0x

Новичок
а как ты собираешься вынуть данные после подсчета - объясни, как после нам роуз будешь вызывать mysql_fetch_array
 

Screjet

Новичок
При fulltext раздуется индекс, а скорость поиска еще более понизится
А, может, таки, полезешь в ман, посмотришь примеры, попробуешь?

зы. Тема на "теоретические вопросы" ну никак не тянет..

Tor
Он все правильно делает.
 

Tor

Новичок
Он все правильно делает.
как же правильно, если кол-во отдельным запросом?
и зачем знать кол-во отдельно по каждой таблице?
вторым запросом выбрали, узнали кол-во и далее по накатанной
 

F0x

Новичок
По каждой - я написал зачем, статистика ведется для каждой таблицы отдельно, убрать ее нельзя. Наверно бы я объединил два первых запроса, если бы это было возможно..
 

Screjet

Новичок
Tor
А не думал, что в результате запроса может быть 100000 записей? или 1000000? Любой хостер тебя затрелит за это, а выделенный сервер будет погибать изза тупости програмера.

Счетчики ему нужны для лимитов запросов.
 

F0x

Новичок
Предложенный fulltext в данном случае бесполезен, поскольку каждый искомый элемент не является целой страничкой текста, но даже не превышает 255 симвоф, то бишь варчар
 

Screjet

Новичок
F0x
Похоже, у вас там тоже кондиционер сломался :)

Давай без абстрактых высказываний:
Примеры таблиц, данных, запросов.
 

F0x

Новичок
Поиск элементов производится по полю с типом varchar.
Тип данных: названия файлов, т.е даже фраза состоящая из нескольких слов, явление редкое.

в случае с фуллтекстом, поле с содержимым 'very_very_very_longfilename.txt' будет добавлено в индекс полностью. Представь чем будет представлен индекс с типом fulltext, если размер обеих таблиц на данный момент уже в сумме завышает 280mb
 

Screjet

Новичок
Представь чем будет представлен индекс с типом fulltext, если размер обеих таблиц на данный момент уже в сумме завышает 280mb
Так чего ты хочешь? Скорости или сэкономить диск?
Определись :)
это же не мешает ему выбирать эти самые записи во втором шаге?
Ага, пририсовав к запросу LIMIT <OFFSET>,<NUM>
 

F0x

Новичок
меня интересует скорость, и я не разделяю мнение о том, что в данном случае fulltext имеет выгоду
 

Screjet

Новичок
я не разделил мнение о том, что в данном случае fulltext имеет выгоду.
Тогда пиши собственные индексы, согласно критериям поиска.
Изобретать велосипед никто не запрещал.

-~{}~ 19.08.05 15:22:

Tor
и что важно, дают возможность использовать полосу навигации страниц - поскольку найденное число результатов уже известно.
 

ssv

Новичок
Автор оригинала: F0x
Предложенный fulltext в данном случае бесполезен, поскольку каждый искомый элемент не является целой страничкой текста, но даже не превышает 255 симвоф, то бишь варчар
Имея огромную базу данных я бы отказался от varchar
в размере бд ты проиграешь, но скорость у тебя увеличится.

А можно ли на сайте выдавать ранжированную статистику.
типа
если записей от 1 -до 10000 выдавать точную статистику,
иначе выводить надпись, типа "записей больше 10000",
т.е. в запросы где подсчет колличества записей добавить лимит

-~{}~ 19.08.05 14:28:

Автор оригинала: F0x
меня интересует скорость, и я не разделяю мнение о том, что в данном случае fulltext имеет выгоду
можно попробовать и сделать точные выводы,
и не забудь поделиться с выводами :)
 

BeGe

Вождь Апачей, блин (c)
Вас интересует скорость в передачи данных от сервера клиенту, или скорость поиска данных, и готовность их отдавать клиенту ?
 
Сверху