Как лучше всего удалить буквальные значения из SQL, чтобы правильно определить рабочую нагрузку базы данных?
Кто-нибудь знает какой-либо код или инструменты, которые могут вырезать буквальные значения из операторов SQL?
Причина этого вопроса заключается в том, что я хочу правильно оценить рабочую нагрузку SQL в нашей базе данных и опасаюсь, что могу пропустить плохие утверждения, использование ресурсов которых маскируется, поскольку они отображаются как отдельные утверждения. Когда на самом деле это почти одно и то же, за исключением того, что передаются разные идентификаторы.
Я бы предпочел независимое от базы данных решение, если оно существует. Я думал, что для этого может быть отличный модуль Perl, но не нашел.
Спасибо за вашу помощь.
Ответы 6
Если вы используете JDBC или что-то подобное, в вашем SQL не должно быть литералов, просто '?' отмечая, где они должны быть.
Только частично верно; это хорошая цель, но на практике она редко достигается.
Итак, вы говорите, что у вас могут быть некоторые плохо выполняющиеся запросы, которые похожи, потому что они построены динамически, и вы хотите, чтобы они были сгруппированы вместе, поскольку они исходят из одного и того же вызова, чтобы общее время, затраченное на выполнение, увеличилось до топ в вашем профиле?
Я думаю, вам придется справиться с этим с помощью регулярного выражения или чего-то еще. Может быть, вы можете передать операторы через претификатор SQL, чтобы сначала они были согласованными, а затем очистить их - буквальные строки должны быть самыми простыми, потому что все они находятся в '' (/'.*'/STRING_LITERAL/), а затем числовые литералы можно выполнить, удалив /\d*/NUMERIC_LITERAL/ или аналогичный.
Да, это именно то, что я ищу. Думаю, ты выразился гораздо лучше, чем я!
Я согласен, что требуется регулярное выражение, поэтому я надеялся, что будет решение для Perl, но пока я его не вижу.
/ -? \ b \ d + \ b / лучше для числовых (ну, целых, во всяком случае) литералов
Думаю, я бы использовал sed, чтобы решить эту проблему. Что-то вроде этого
$ cat sql.txt
SELECT * FROM USER WHERE USERID = 123 OR USERNAME LIKE 'Name1%'
SELECT * FROM USER WHERE USERID = 124 OR USERNAME LIKE 'Name2%'
SELECT * FROM USER WHERE USERID = 125 OR USERNAME LIKE 'Name3%'
SELECT * FROM USER WHERE USERID = 126 OR USERNAME LIKE 'Name4%'
$ sed -e "s/\([0-9]\+\)\|\('[^']*'\)/?/g" sql.txt
SELECT * FROM USER WHERE USERID = ? OR USERNAME LIKE ?
SELECT * FROM USER WHERE USERID = ? OR USERNAME LIKE ?
SELECT * FROM USER WHERE USERID = ? OR USERNAME LIKE ?
SELECT * FROM USER WHERE USERID = ? OR USERNAME LIKE ?
p.s. Если бы кто-нибудь мог прокомментировать, как избежать всех этих побегов, он был бы очень признателен.
SQL :: Заявление, в частности модуль SQL :: Заявление :: Структура, позволит вам анализировать операторы SQL и управлять ими. Подмножество синтаксиса SQL, которое он понимает, можно увидеть здесь.
В соответствующем примечании есть DBI :: Профиль, чтобы помочь с анализом производительности.
Спасибо, Шверн. Похоже, это именно то, что мне нужно.
Я знаю, что вам нужен вариант, независимый от базы данных, но если вы используете Microsoft SQL Server, бесплатные MS ReadTrace (для SQL 2005) и Read80Trace (для SQL 2000) делают именно это. Они берут выходной файл трассировки и удаляют литералы. Я также не видел независимого от db решения (и я работаю в Quest Software, авторе db-независимых инструментов).
http://blogs.msdn.com/psssql/archive/2007/12/18/rml-utilities-for-microsoft-sql-server-released.aspx
Поисковая машина исходного кода Semantic Designs сделает это тривиально, используя его сканер SQL.
Поисковая система анализирует исходный код для создания лексем, включая именно те буквальные строки, которые вы после. Индексирует все лексемы и использует этот индекс, чтобы вы могли искать / просматривать ваш источник кодовая база (даже если она огромная) в интерактивном режиме.
Запрос поисковой системы: S (да, просто S) найдет все буквальные символы «S» в вашем тексте SQL. Все результаты запроса отображаются в окне обращений, и вы можете щелкните свой путь прямо, чтобы просмотреть рассматриваемый код из любого ударить. Есть средство ведения журнала, которое будет записывать все хиты для последующего анализа.
http://www.semanticdesigns.com/Products/SearchEngine/index.html
Спасибо за ответ. К сожалению, мы иногда получаем sql-операторы, отправленные с буквальными значениями, а не с привязанными переменными, и у меня (пока) нет возможности получить разработку для исправления запросов.