Где лучше фильтровать данные из БД?

Question

[Snort]

Не знаю как лучше сделать отбор данных, есть табличка в бд в которой 8 полей из них нужно фильтровать данные по 5 полям, думал сделать простым запросом "SELECT * FROM table WHERE col1 = '1' AND col2 LIKE '%2% AND col3 REGEXP '\s''' примерно так, в таблице не более 20 строк, но они периодически меняются. Всего планируется что будет ~600к таких селектов в день и столько же инсертов в другие табличке на основании полученных данных. Или лучше будет получить все данные из это таблице и в php сделать отбор? Очень важна скорость работы скрипта. Mysql выбрал потому что с ним только и работал) Вообщем товарищи эксперты, подскажите как лучше сделать и что можно применить для увеличения быстродействия(другой тип базы,или какой ни будь кеш сделать)

Answer 1

[Inteli Sense]

SELECT сам по себе быстрый если в нем нет JOIN. 600к строк проблема если серверу уже лет 20 и обрабатывает он как минимум еще около 10к людей.

Почитайте про настройку MySQL
Так же про Индексирование

Ну, а если еще захотите использовать некое кеширование то тут я не силен - скажу только что использую в первом запросе сохранение данных с него в кеш и периодически обновляю ID строк которые туда попадают.

Всего найлучшего!

Comments

[Антон Шаманов]

А кеширование в данном случае и не особо поможет, только если сразу генерировать статику

[Inteli Sense]

Anton: Если получать с первого раза только результирующие - записывать их и потом с помощью них выбирать из IN то мне кажется будет быстрее чем генерировать статику.

[Snort]

Спасибо за ссылки)) Сервер мощный, но тут и получается что один человек один селект+инсерт. Join сильно замедляет запрос? А если вместо joina использовать подзапрос: "SELECT * FROM table1 WHERE col1 = (SELECT col2 FROM table2 WHERE table1.id = table2.id)" так лучше будет?

[Inteli Sense]

Snort: А вам нужен этот Join - я его просто так упомянул ибо у вас простой селект с критериями. Тут сам вопрос в кешировании - нужно оно вам или нет. тут вам придется ссылки искать самому - все в основном зависит от настроек и идексирования. Прогнать Mysql можно mysqltuner.com

[Сергей Протько]

Snort: у вас выходит зависимость по данным с подзапросом, в этом случае MySQL не будет особо пытаться это дело оптимизировать. С JOIN-нами хотя бы есть варианты и прогнозируются они лучше.

[FanatPHP]

OMG, "SELECT сам по себе быстрый если в нем нет JOIN." щутите пожалуйста бред - который вы только что изложили.

Answer 2

[Сергей Иванов]

Полагаю,что проще будет через php. По моему LIKE работает очень медленно и php вроде с этим справится быстрее.

Comments

[Антон Шаманов]

а на каких тестах основывается данное утверждение?

[Inteli Sense]

Writerim: Ощутите пожалуйста бред - который вы только что изложили.

[Сергей Иванов]

Anton:

MYSQL:

SELECT *
FROM `parameter`
WHERE ident LIKE '%Y%'
LIMIT 0 , 30

Отображает строки 0 - 2 ( 3 всего, Запрос занял 0.0194 сек.)

PHP:

$start = microtime(true);

$db = mysql_connect("*****","***","****");
mysql_select_db("****" ,$db);
$sql = mysql_query("SELECT * FROM parameter" ,$db);
while ($tablerows = mysql_fetch_assoc($sql))
{
if(preg_match('/(.*+)Y(.*+)/' , $tablerows['ident'])){
echo 1;
}
}

echo 'Время выполнения скрипта: '.(microtime(true) - $start).' сек.';

Время выполнения скрипта: 0.0021300315856934 сек.

На 20 записях возможно не будет так заметно, но по большому счету LIKE не рекомендуют пользоваться.

[Сергей Иванов]

Aios: use-the-index-luke.com/sql/where-clause/searching-...

[FanatPHP]

Милый. Ты бы попробовал "не на 20 записях". Авось дойдет, что за Бред ты написал

Answer 3

[FanatPHP]

Если речь о 20-и строках, то вопрос о скорости не имеет смысла. Можешь делать в базе, можешь в скрипте, а можешь попеременно - на скорости это никак не скажется.

В целом же, для нормальных, а не микроскопических баз данных, любую фильтрацию надо делать только в базе.

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