простейшая ф-я для форматирования телефонов почему-то работает медленнее, чем "руками":



запрос


отрабатывает за 0.70
а такой:


за 0.05

так задумано?

а ещё она в mysql.func почему-то не пишется

tip78а ещё она в mysql.func почему-то не пишется
а, ну это потому что там только AGGREGATE, а пользовательские в mysql.proc

bochkovдумаю , что не хватает оптимизатору
DETERMINISTIC и NO SQL
в определении функции
ничего не дало

вот в таком виде ф-я отрабатывает уже за 1 секунду:


было 0.65
и это на 43к строках...
т.е. такая огромная просадка в 50% из-за простого добавления переменной
очевидно, что ф-я не кешируется, а каждый раз как-будто бы компилируется заново, на каждой из 43к строк
чего-то я упускаю, а что?

ну походу так и задумано ...
для добычи счастья надо UDF-ы писать походу

Yes, stored procedures are slow, a bunch of magnitudes slower than interpreted/compiled code. They turn out useful when you need to tie up some database logic which you want to keep out of.
your application because it's out of the specific domain (ie, logging/administrative tasks). If a stored function contains no queries, it's always better practice to write an utility.
function in your chosen language, as that wont prevent reuse (there are no queries), and will run much faster.

nope the direct query is a lot faster; i assumed as a given fact that stored functions are inherently slower than interpreted/compiled code and just wanted to show you a better.
implementation; btw when stored function/procedures contain no queries, it's always better to implement the same as an external function.

My answer, in summary, is that the custom function was being called up 7000 times in a query and not 300 times as I originally thought. 300 times would be fine for this report, taking about.
10 seconds. 7000 times takes over 3 minutes and is no good.
The reason is that the custom function in the SELECT clause gets applied to all rows retrieved in the query before the GROUP BY clause is applied. The GROUP BY reduces the 700 rows.
retrieved to just 30 unique rows.

This has been a flaw of MySQL for a long time - sub-queries are executed for each outer query match returned, even if the sub-query is not linked to the outer query. The optimiser should be.
able to work out that there is no point executing the sub-query or custom function on rows that are going to be discarded through the WHERE clause conditions.