Комментарии 23
Как раз сейчас пишу статью про Prepared Statements. Предположительно, опубликую на выходных.
ШАГ 4. Создание некластерного индекса. А если к этому еще взять в добавой какой либо SQL 7 или болнее древний, то может работать и еше медленне. А вообще, если сильно постараться, то и вовсе работать не будет.
Пример изрядно прятянут за уши. Всегда можно напридумыватиь ситуацию в которой наиболее правильное решение отличается от обшепринятого.
Пример изрядно прятянут за уши. Всегда можно напридумыватиь ситуацию в которой наиболее правильное решение отличается от обшепринятого.
Не стОит. Пожалуйста.
Поясните, пожалуйста, почему?
Болдом - От подзапросов можно отказаться в 99% случаев
И тут же пример неработающего подзапроса
SELECT u.name user_name, (SELECT dep.name FROM DEPARTMENT dep WHERE u.department_id = dep.department_id) dep_name
FROM USERS u
WHERE u.user_id = ?
Автор вообще не в курсе что такое подзапросы и с чем их едят?
Болдом - Везде, где можно, используйте Prepared Statements.
Песдец. Ни один человек который работал с БД на серьезном уровне не будет категорично утверждать.
"Дело в том, что поступающие запросы анализируются СУБД и сохраняются в кэше." В кэше хранятся а. "результаты выполнения запроса"(совершенно по барабану от какого пользователя они пришли) б. План исполнения запроса. в. Много чего ещё. Вобщем с тем же успехом можно было написать Никогда не используйте препаред стэйтментс План по ним не пересчитывается и вся статистика индексов, оптимальные планы - идут коту подхвост. Жаль длина коммента ограничена.
И тут же пример неработающего подзапроса
SELECT u.name user_name, (SELECT dep.name FROM DEPARTMENT dep WHERE u.department_id = dep.department_id) dep_name
FROM USERS u
WHERE u.user_id = ?
Автор вообще не в курсе что такое подзапросы и с чем их едят?
Болдом - Везде, где можно, используйте Prepared Statements.
Песдец. Ни один человек который работал с БД на серьезном уровне не будет категорично утверждать.
"Дело в том, что поступающие запросы анализируются СУБД и сохраняются в кэше." В кэше хранятся а. "результаты выполнения запроса"(совершенно по барабану от какого пользователя они пришли) б. План исполнения запроса. в. Много чего ещё. Вобщем с тем же успехом можно было написать Никогда не используйте препаред стэйтментс План по ним не пересчитывается и вся статистика индексов, оптимальные планы - идут коту подхвост. Жаль длина коммента ограничена.
Ради эксперимента разместите эту статью на SQL.ru. В лучшем случае за такое дилетанство и категоричный тон - прострелят коленку. Естественно речь идет не о абсолютно грамотной статье выше а о Как правильно писать SQL-запросы (одно название чего стОит)
И да, вот, например, отличная статья для тех кто планирует всерьез работать с базами данных
Двадцать пять заповедей SQL
Двадцать пять заповедей SQL
Очень редко встречаю таблица с неравномерным распределением данных... Так что это скорее вырожденный случай, как и тот в котором ereg уделывает preg раз в 100 если мне не изменяет память. Но всё же бывают такие данные, так что как заметка - учтёмс.
Это одна из особенностей, которую я не отметил в предыдущей статье. Она состоит в том, что надо учитывать особенность данных. Хотя в большинстве стучаев данные все-таки достаточно равномерные и, если, случилась ситуация, описанная в статье, то вы наверняка знаете об особенности данных в этой таблице.
Вы работаете только с первичными ключами? Распространенный случаи разной селективности значений столбца - статусы, флаги и т.п.
Спасибо вам за комментарии!
В постгресе (8.3.1, AltLinux) замечена следующая штука - стандартное поведение запроса - первый раз он отрабатывает, к примеру, за 10 mc, последующие (пока сам запрос валяется в кеше) - 2 - 3. При использовании prepared statement поведение меняется - первый и все последующие запросы выполняются за те же 10 mc. Связано это, скорее всего, с тем, что prepared statement выполняется через команду execute - т.е. всегда выполняется и никогда не берется из кеша - сохраняется только план обработки запроса. Соответственно, при использовании постоянных соединений использование prepared statement может на отдельных задачах (когда в рамках одной сессии к базе идет несколько не просто сходных, но одинаковых запросов) не только не дать прироста производительности, но наоборот обеспечить просад.
предупреждая вопросы, зачем нужно многократное повторение одного и того же запроса - замечено дополнительное кеширование результатов запросов вида что-то-там=ANY(массив - вообще говоря большой или, вернее - растущий) - соответственно при расширении массива скорость его обработки растет нелинейно в случаях, если такое расширение происходит постепенно и каждый следующий массив (расширенный) включает в себя предыдущий .
Может, логичнее было бы дать ссылку на "Производительность хранимых процедур в MS SQL Server 2005" ? 2000 уже устарел, имхо. Ведь уже совсем скоро и 2008 выйдет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
RE: Как правильно писать SQL-запросы