|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Таблица MyISAM 6 полей, при поиске количества с запросом: name_en LIKE 'a%' или RLIKE'^[0-9]', время состаавляет 13 сек. Сам запрос SELECT SQL_CALC_FOUND_ROWS id, name_en,url,description,activity_id FROM objects_info USE INDEX(name) WHERE name_en LIKE 'a%'
CREATE TABLE `objects_info` (
`id` int(10) unsigned NOT NULL,
`name_en` varchar(255) character set cp1251 collate cp1251_ukrainian_ci NOT NULL,
`url` varchar(255) collate cp1251_bin NOT NULL default '',
`activity_id` int(10) unsigned NOT NULL,
`description` varchar(255) character set cp1251 collate cp1251_ukrainian_ci default NULL,
`regdate` int(10) NOT NULL default '0',
`status` tinyint(4) NOT NULL default '1',
PRIMARY KEY (`id`),
FULLTEXT KEY `name` (`name_en`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COLLATE=cp1251_bin
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE objects_info ALL name NULL NULL NULL 2870540 Using where
Помогите пожалуйста! как его можно ускорить?
Неактивен
А почему нв INDEX а FULLTEXT?
странно, почему-то всеравно не срабатывает индекс
http://mysqlinfo.ru/text_MySQLindexes.htm написал:
MySQL применяет индексы также для сравнений LIKE, если аргумент в выражении LIKE представляет собой постоянную строку, не начинающуюся с символа-шаблона. Например, следующие команды SELECT используют индексы:
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Pat%_ck%";
В первой команде рассматриваются только строки с "Patrick" <= key_col < "Patricl", а во второй - только строки с "Pat" <= key_col < "Pau".
Следующие команды SELECT не будут использовать индексы:
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "%Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE other_col;
В первой команде величина LIKE начинается с шаблонного символа. Во второй команде величина LIKE не является константой.
может здесь играет роль: CHARSET, COLLATE (дб, таблицы и поля)?
кстати это: SELECT SQL_CALC_FOUND_ROWS id, name_en,url,description,activity_id FROM objects_info USE INDEX(name) WHERE name_en LIKE 'a%'
никак не SELECT count(*) FROM objects_info WHERE name_en LIKE 'a%' // здесь кстати индекс срабатывает!
Отредактированно vaspet (13.03.2009 11:57:43)
Неактивен
А вот это подходит:
В некоторых случаях MySQL не использует индекс, даже если это возможно. Несколько примеров таких ситуаций приведено ниже:
* Если использование индекса требует от MySQL прохода более чем по 30% строк в данной таблице (в таких случаях просмотр таблицы, по всей видимости, окажется намного быстрее, так как потребуется выполнить меньше операций поиска). Следует учитывать, что если подобный запрос использует LIMIT по отношению только к извлекаемой части строк, то MySQL будет применять индекс в любом случае, так как небольшое количество строк можно найти намного быстрее, чтобы вернуть результат.
Отредактированно vaspet (13.03.2009 11:53:13)
Неактивен
Полнотекстовый индекс — хорошая штука, нужно только «уметь его готовить». Запрос к полнотекстовому
индексу производится через WHERE MATCH (name_en) AGAINST ('word');
P.S. У нас появился конкурент? 
Неактивен
Я его и использую, в тех случаях когда 'word' более 3-х символов, если же меньше то Like 'word%'. С фултектсным поиском у меня все хорошо - работает быстро, а вот напр. Like "а%" работает не очень - 13 сек - это поиск количества. Не понимаю как гугл выбирает 48 млн. за 0.24 сек.
Отредактированно LossBul (13.03.2009 12:49:36)
Неактивен
Когда не использую в запросе USE INDEX (name) то вообще работает 240 сек.. name - это фултекст индекс.
Неактивен
Для поиска LIKE 'a%' нужен обычный индекс. Но осмысленность такого запроса на 3кк записей —
чрезвычайно сомнительна.
Поисковые системы не используют базу MySQL для основного поиска. И, разумеется, они располагаются
не на одном компьютере 
Неактивен
Так что получается нет никаких способов ускорить этот процесс? Наверное тогда придется отказкться от поиска количества
Неактивен
paulus написал:
Для поиска LIKE 'a%' нужен обычный индекс. Но осмысленность такого запроса на 3кк записей —
чрезвычайно сомнительна.
Поисковые системы не используют базу MySQL для основного поиска. И, разумеется, они располагаются
не на одном компьютере
Я использовал обычный индекс, никакой разницы между простым и фултекстным я не ощутил, время не изменилось
Неактивен
помоему
SELECT SQL_CALC_FOUND_ROWS
иммет смысл только, если вы используете LIMIT
А если вы используете LIMIT, то индекс (обычный) сработает
может, тогда лучше использовать последовательность:
1. ваш запрос (без SQL_CALC_FOUND_ROWS)
2. SELECT count(*) FROM objects_info WHERE name_en LIKE 'a%' // здесь обычный индекс срабатывает
Что скажут эксперты?
Неактивен
vaspet написал:
помоему
SELECT SQL_CALC_FOUND_ROWS
иммет смысл только, если вы используете LIMIT
А если вы используете LIMIT, то индекс (обычный) сработает
может, тогда лучше использовать последовательность:
1. ваш запрос (без SQL_CALC_FOUND_ROWS)
2. SELECT count(*) FROM objects_info USE INDEX(name) WHERE name_en LIKE 'a%' // здесь обычный индекс срабатывает
Что скажут эксперты?
Да лимиты я использую, запрос с SQL_CALC_FOUND_ROWS работает в 2 раза быстрей чем SELECT count(*) FROM objects_info USE INDEX(name) WHERE name_en LIKE 'a%', тоесть 13 и 24 сек. соответственно
Отредактированно LossBul (13.03.2009 13:52:12)
Неактивен
SELECT count(*) FROM objects_info WHERE name_en LIKE 'a%'
на name_en должен быть обычный индекс!
Мне кажется такой запрос летать должен!?
А вот не поленился забил вашу табличку 2кк записями и выше написанный запрос летит менее 0,2 сек.
Отредактированно vaspet (13.03.2009 15:22:02)
Неактивен
Да, но Вы то добавили обычный индекс, а LossBul — нет )
Неактивен
paulus написал:
Да, но Вы то добавили обычный индекс, а LossBul — нет )
Значит решением проблемы будет создание обычного индекса. Тогда вопрос: можно ли создать на одно поле (name_en) два отдельных индекса - обычного и фултекстного, а в запросе потом прописывать USE INDEX (имя_нужного_индекса). Возможно ли такое?
Неактивен
Да, возможно, конечно.
И все-таки, я считаю, что поиск вида «найди все, что начинается с а» — не осмысленный.
Неактивен
И все-таки, я считаю, что поиск вида «найди все, что начинается с а» — не осмысленный.
Возможно но это условие заказчика. Всем большое спасибо!
Неактивен
Страниц: 1
