MySQL: Хранимые процедуры и динамический SQL

Ну если инъекция добралась до автособираемого sql-я, то это дыра в разработчике.

Для MS SQL, например, это не так. Его оптимизатор позволяет сохранять планы даже для динамического SQL. План, грубо говоря — это распарсенное до атомарных операций выражение SQL, готовое к выполнению. После первого парсинга план помещается в кэш, после чего для его использования не нужно нагружать парсер, достаточно просто взять из кеша нужный запрос и подставить параметры.

Понятно, что параметризовать именем таблицы нельзя, зато можно держать планы для всех таблиц в БД (их редко бывает больше сотни-другой) для среднего проекта.

С другой стороны, наличие динамического sql, как правило, говорит о том, что что-то не так в датском королевстве вы используете БД не по назначению, заставляя ее выполнять задачи сервера приложений.

Вон оно как.

А я тупой думал, что когда из клиента запрос на сервер шлю — сервер его сначала парсит и только потом выполняет. И вообще сдуру думал, что любой запрос, если он не в хранимой процедуре, для сервера динамический и его парсить надо.

Спасибо за просветление.

Так все таки, вообще нельзя с клиента запросы слать или они пока до сервера доходят волшебным образом парсятся?

Согласен, незаметил.

а то даже может и суффикс =)

и еще,
SET @archive_query:=CONCAT
(«CREATE TABLE »,template," ENGINE=ARCHIVE AS
(SELECT * FROM ",current_table," )");

Тут обязательно после CONCAT-а нужно поставить открывающую скобу на этой же строке, иначе mysql будет ругаться, что мол нет такой процедуры CONCAT

Если у нас таблички t1, t2 для наглядности их JOIN без условия

select name1,d1,name2,d2 from t1 left join t2 on t1.name1=t2.name2


+---------+------+---------+----------+
| name1   | d1   | name2   | d2       |
+---------+------+---------+----------+
| name1   | d1   | name1   | x_d2_x   |
| name11  | d11  | name11  | x_d11_x  |
| name111 | d111 | name111 | x_d111_x |
+---------+------+---------+----------+

То запрос будет выглядить так

select name1,d1,name2,d2 from t1 left join t2 on t1.name1=t2.name2 where LOCATE(d1,d2)


Логика тут такая LOCATE() возвращает позицию вхождения подстроки. Если внутри d2 содержится d1, то мы получим положительное число.
Получим соотвественно:

+---------+------+---------+----------+
| name11  | d11  | name11  | x_d11_x  |
| name111 | d111 | name111 | x_d111_x |
+---------+------+---------+----------+

То есть запись где было d2=x_d2_x была отброшена.

Можно дергать процедуру и выгружать данные в темповую таблицу, конечно не очень красиво, но вполне рабочий вариант.

А какие проблемы.
Если в результате выполнения запроса получается выборка с одним полем — GROPUP_CONCAT на него INTO myvar.
Дальше собрать запрос CONCAT'ом и выполнить.
Если одно значение просто его в переменную.
Если набор строк с несколькими полями, то IMHO лучше на клиента вернуть и там обработать, а по результатам новый запрос отправить. Тут нередко и кэш может помочь.

С темповой таблицей поаккуратнее, она ведь может и на диске образоваться, естественно в самый подходящий момент, в неподходящий, когда нагрузки нет — ей в оперативке места хватит. :)

Действительно удобней. Но здесь задача стояла как такое сделать средствами MySQL

Ну почему же, они компилируются при PREPARE. Можно один раз PREPARE и кучу раз EXECUTE.

Сам по себе это — инструмент, который можно использовать. И хорошо, что он есть. А уж как его использовать — решать разработчику.