Mysql Долго выполняется запрос, как ускорить

[peon]

Поменял местами formalname и shortname, теперь 0.0856 сек.

SELECT formalname
FROM  `d_fias_addrobj`
WHERE formalname LIKE  'К%'
AND shortname =  'г'
ORDER BY formalname
LIMIT 0 , 10

 

[c0dex]

peon, не надо ничего там вставлять, делается апдейт средствами mysql и все.

Сейчас у тебя очень длинный ключ на поле formalname, который для подобного запроса и не нужен вовсе. Фанат верно подметил, что можно ограничить длину индекса до первого символа. Но я бы сделал все равно композитный ключик.

 

[Фанат]

Не радуйся раньше времени

SELECT SQL_NO_CACHE formalname
FROM `d_fias_addrobj`
WHERE formalname LIKE 'К%'
AND shortname = 'г'
ORDER BY formalname
LIMIT 0 , 10

и посмотри сколько займет

 

[peon]

Не радуйся раньше времени

SELECT SQL_NO_CACHE formalname
FROM `d_fias_addrobj`
WHERE formalname LIKE 'К%'
AND shortname = 'г'
ORDER BY formalname
LIMIT 0 , 10

и посмотри сколько займет

0.0858 сек.
пощелкат несколько раз оба запроса, скорость выполнения одинаковы

 

[c0dex]

Фанат, есть у меня к тебе вопрос, как к знатоку.
Мне казалось, что SQL_NO_CACHE не дает положить данные в кеш, но не запрещает их оттуда доставать, даже при условии наличия SQL_NO_CACHE в запросе при повторном запуске. Я ошибся?

ЗЫ: Ошибся. http://dev.mysql.com/doc/refman/5.0/en/query-cache-in-select.html Пруфлинк в втором абзаце =\

 

[Фанат]

Фанат, есть у меня к тебе вопрос, как к знатоку.
Мне казалось, что SQL_NO_CACHE не дает положить данные в кеш, но не запрещает их оттуда доставать, даже при условии наличия SQL_NO_CACHE в запросе при повторном запуске. Я ошибся?

В данном случае я не знаток, а эмпирик. И был всегда уверен в обратном, что не дает именно исползовать. Впрочем, внести ясность легко

SQL_NO_CACHE
The server does not use the query cache. It neither checks the query cache to see whether the result is already cached, nor does it cache the query result.

- как видим, и то и другое

 

[Фанат]

все равно не понимаю, почему разница. Может, индекс прогрелся?

 

[c0dex]

Так ТС говорит, что сейчас нет разницы. Начал читать http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/ про кеш и то как считать эффективность, запустался нахрен. Перечитываю =(

 

[Breeze]

все равно не понимаю, почему разница. Может, индекс прогрелся?

статистика изменилась, например из-за какого-то alter

 

[c0dex]

Самое забавное, что я выцепил в мануале про кеш.

Fragmentation over time – Over time Query Cache might get fragmented, which reduces performance. This can be seen as large value of Qcache_free_blocks relatively to Qcache_free_memory. FLUSH QUERY CACHE command can be used for query cache defragmentation but it may block query cache for rather long time for large query caches, which might be unsuitable for online applications.

То есть со временем мы можем поиметь performance degradation.

Demand operating mode If you just enable qury cache it will operate in “Cache everything” mode. In certain caches you might want to cache only some of the queries – in this case you can set query_cache_type to “DEMAND” and use only SQL_CACHE hint for queries which you want to have cached – such as SELECT SQL_CACHE col from foo where id=5. If you run in default mode you can also use SQL_NO_CACHE to block caching for certain queries, which you know do not need to be cached.

То есть можно кешировать только нужные запросы и не писать везде SQL_NO_CACHE/вырубить кеш вообще.

Avoid comment (and space) in the start of the query – Query Cache does simple optimization to check if query can be cached. As I mentioned only SELECT queries are cached – so it looks at first letter of the query and if it is “S” it proceeds with query lookup in cache if not – skips it.

Забавно, как-то даже не думал об этом.

Due to a limitation in the parser, a space character must precede and follow the SQL_NO_CACHE keyword; a nonspace such as a newline causes the server to check the query cache to see whether the result is already cached.

Самое забавное, что если где не так напишешь текст запроса, то хрен будет работать сброс кеша =)

 

[Фанат]

статистика изменилась, например из-за какого-то alter

да там вроде простой эксплейн, который никакой статистикой не испортишь

 

[Breeze]

да там вроде простой эксплейн, который никакой статистикой не испортишь

оптимизатор хитрый, иногда.

 

[Фанат]

оптимизатор хитрый, иногда.

Ну, "унутре у ней неонка" - это, конечно, ответ. Но любопытство не очень удовлетворяет

 

[флоппик]

у него key_len в эксплейне 312. Готов спорить, что запрос еще сильнее можно разогнать, насильно указав индексу маленькую размерность.

 

[WMix]

shortname - по ходу тоже индекс..

 

[Фанат]

или даже просто поменяв кодировка на однобитную.
как раз сейчас этим у себя занимался - все варчарные проиндексированные поля урезаются до минимально возможной блины и ставятся в латин1.
поскольку для чпу утф нафиг не сдался

 

[Breeze]

Ну, "унутре у ней неонка" - это, конечно, ответ. Но любопытство не очень удовлетворяет

Самому интересно
где-то полгода назад:

есть запрос с кучкой join и order by, есть два индекса на основную таблицу. эксплейн показывает первый индекс, using temporary и filesort. запрос работает 0,8с
добавляем для другого запроса свой индекс. и, вуаля, первый запрос юзает второй индекс, эксплейн показывает using where, а время 0,005с
разумеется все с выключеным кешом

фактически альтер сделал как минимум analyze и изменил статистику, которую оптимизатор стал юзать с намного большим успехом

конечно "неонка", но весьма забавная

 

[Фанат]

конечно "неонка", но весьма забавная

Ну тут-то индекс 1 вообще.
И, как я понимаю, експлейн не менялся.

 

[Breeze]

значит еще что-то поменялось, сделал какой-то optimize сам того не подозревая.
страницы могли быть забиты мусором, который вычистился, вот и стало быстрее.

DDL он так и не показал

 

[Breeze]

кстати, что касается кеша запросов. кто-то недавно возмущался тем, что очередной апдейт mysql 5.6 принес кеш выключенным по дефолту