вадя,

те результаты я опроверг, все выложено.

хочешь не хочешь там предоставлены факты, И долгое время работы запросов у тебя на предыдущей версии было связано с поломанным индексом. Я тебе там это описал. Все данные для проверки я дал. Проверено на нескольких версиях. Ты таких полных тестов так и не сделал.

вадяAlex_Ustinovхочешь не хочешь там предоставлены факты, И долгое время работы запросов у тебя на предыдущей версии было связано с поломанным индексом. Я тебе там это описал. Все данные для проверки я дал. Проверено на нескольких версиях. Ты таких полных тестов так и не сделал.
я делал тесты под свои задачи и видел результат - мне этого достаточно.
поломанного индекса в моих тестах я не нашёл...
в общем спор бессмыслененн.
like у меня работает быстро, мне это нравится :) это не спор, это факты, таблицы я генерировал случайными данными, я же тебя спрашивал в том топике - оказалось, что ты просто обновился до 5.7 на Линукс из репы, не тестируя на прежних версиях. А я их проверил, все возможные у меня стоят рядом. Я даже сейчас помню - это было воскресенье, мною потрачен почти целый рабочий день. А ты все свое глаголишь. Тесты показали что работает Лайк одинаково. Ты просто не можешь на Линукс поставить два экземпляра рядом, научись, поставь и проверь, не умеешь в Линуксе - скачай в Вайне uninstall версии и запускай демон "mysqld --console". Самое интересное, что когда у меня сломался индекс в 5.7 - работало также как и у тебя на сломаном индексе в 5.5 (или 5.6, что там ранее у тебя стояло). Я тебе явно показал, Что же это Такое - работа индекса, на примере WERE like "финд%" т.е. поиск с начала строки (выполнение почти мгновенно) и like "%финд% (~ >3 сек). 3 секунды - это отсутствие работы индекса. В плане просто как бы показывается что он используется и все. То же время выполнения было и в 5.5 (без указания использования индекса в плане). Это факты, я не считаю это спором. В ветке Оракла (там это действительно работает) попроси ребят сравнить время выполнения двух лайков - они тебе скажут, что есть на самом деле работа индекса

вадя,

Свои исследования я проделылвал на 2млн записей, подсчитав, что он у меня не помещается в память (на домашней ПК) и этого достаточно
http://dev.mysql.com/doc/refman/5.7/en/index-btree-hash.html 9.3.8 Comparison of B-Tree and Hash Indexes

Understanding the B-tree and hash data structures can help predict how different queries perform on different storage engines that use these data structures in their indexes, particularly for the MEMORY storage engine that lets you choose B-tree or hash indexes.

B-Tree Index Characteristics

A B-tree index can be used for column comparisons in expressions that use the =, >, >=, <, <=, or BETWEEN operators. The index also can be used for LIKE comparisons if the argument to LIKE is a constant string that does not start with a wildcard character. For example, the following SELECT statements use indexes:

SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
In the first statement, only rows with 'Patrick' <= key_col < 'Patricl' are considered. In the second statement, only rows with 'Pat' <= key_col < 'Pau' are considered.

The following SELECT statements do NOT use indexes :

SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE other_col;
там же НИЖЕ - при поисковой строке больше 3-х символов попадаем на непредсказуемый Алгоритм Turbo Boyer-Moore (а НЕ Индекс)
http://dev.mysql.com/doc/refman/5.7/en/index-btree-hash.html If you use ... LIKE '%string%' and string is longer than three characters , MySQL uses the Turbo Boyer-Moore algorithm to initialize the pattern for the string and then uses this pattern to perform the search more quickly.

вадя,

устраивает - это замечательно.
Только если это одиночный запрос и устраивает - это хорошо. А если к такому запросу приджойнить еще таблицу с таким псевдо использованием индекса - это будет крах системы.
Просто не надо вводить в заблуждение других, в 5-10 раз скорость в 5.7 возрасти не могла и т.д. Если так оказалось - это случайный факт

не исследована причина долгого выполнения запросов в предыдущих версиях - поэтому кажется очень заметно.