mysql хранит рутину против mysql-альтернативы?

Мы используем базу данных mysql с примерно 150 000 записей (имен). Наши поиски в поле «имена» выполняются с помощью функции автозаполнения в php. У нас есть таблица, индексированная, но все еще чувствую, что поиск немного вялый (несколько полных секунд против чего-то вроде Google Finance с почти мгновенным ответом). Мы пришли к ж/2 возможности, но хотели бы получить более глубокое представление:mysql хранит рутину против mysql-альтернативы?

Может ли мы создать кучу (много тысяч или больше) хранимые процедуры для ускорения поиска, или создавать что многие хранимых процедур bog- вниз по дБ?
Есть ли более быстрая альтернатива mysql для операторов «select» (скорость при вставке & обновления строк не слишком важна, поэтому мы можем принести в жертву, если это необходимо). Я смутно слышал о BigTable & других, которые не поддерживают инструкции JOIN .... нам нужны операторы JOIN для некоторых наших других запросов, которые мы делаем.

ТНХ

источник

2011-01-18 Marissa Levy

Остановить. Вы пробовали http://dev.mysql.com/doc/refman/5.1/en/optimization.html? Обычно производит фантастические результаты, особенно при первом использовании. – Osw

Я буду читать по кешированию. Есть ли там хороший документ (или видео), в котором сравниваются сильные/слабые стороны каждой из основных баз данных (т.е. mysql vs. oracle vs. cassandra и т. Д.)? Прежде чем я углубится в mysql, я хочу убедиться, что у меня есть правильный d-base –

Wait, 'select name from names где name, как 'foo%' limit 10' занимает секунды ?! Это не должно. Это простая операция индекса. Вы уверены, что у вас есть индексы? Пожалуйста, дайте примерный запрос вместе с выводом 'explain'. – derobert

Забудьте о хранимых процедурах. Они не помогут вам.
Mysql - хороший выбор, его часто считают самой быстрой СУБД. И нет необходимости искать «более быструю альтернативу выборке».

Неопределенное время выполнения запроса, о котором вы упомянули, является результатом неправильной конфигурации сервера или неправильной схемы базы данных или обоих. Пожалуйста, прочитайте this response on serverfault или обновите свой вопрос здесь: укажите конфигурацию сервера, часть схемы базы данных и запрос проблемы, а также explain select ...

источник

2011-01-18 09:02:38 Osw

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

источник

2011-01-18 00:56:29 Bnjmn

будет иметь тысячи и тысячи операторов select в кэше, чтобы замедлить нас, хотя? Пример закрытий, который у меня есть, - функция автопоиска Google Finance .... будет хранить все вызовы для тикеров (и частичных тикеров) в кеше, или они, вероятно, делают что-то еще? –

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

несколько сотен тысяч записей не проблема для кеша. –

Да, вы должны истечь кеш, если вы меняете данные, но, как вы сказали, это не является обычным явлением, поэтому вы можете даже сделать это на полуавтоматической основе и не беспокоиться об этом, если это необходимо. Вы должны проверить this MySQL.com article, а также, возможно, изучить механизм хранения MEMORY (извините, новый и не может размещать более одной гиперссылки на сообщение ?!), который требует немного кодирования для использования, но может быть чрезвычайно эффективным.

Каково фактическое время запроса (против времени страницы)? На достаточно современном сервере, который не загружен в ад, MySQL должен иметь возможность делать запрос автозаполнения на 150 тыс. Строк намного, гораздо быстрее, чем на две секунды. Отсутствуют некоторые индексы?

источник

2011-01-18 02:33:34 tkrajcar

mysql хранит рутину против mysql-альтернативы?

ответ

Смежные вопросы