Навигация · Сделать домашней страницей · Добавить в избранное · Мобильный Tencent · Домашняя страница Tencent Новости Блог Форум Комментарии Финансы Ценные бумаги Гонконг Фондовые фонды Развлечения Звезды Кино Музыка Спорт НБА Футбол Комплексные автомобили Недвижимость Бытовая техника Технологии Цифровые мобильные загрузки Женские эмоции Воспитание детей Мода Шопинг Путешествия Чтение Оригинал Образование «Выезд за границу» Игры Аниме Анимация Созвездия Видео Live Pictures Expo Благотворительность Дети Новые популярные Горячие китайские золотые диски Посетите красочный мир моды и предметов роскоши Национальные бестселлеры Мобильные телефоны Следуйте рейтинговому списку, чтобы узнать, у каких знаменитостей сегодня день рождения. Ваше местоположение: Tencent. Домашняя страница > Технологии и цифровые технологии > Новости Digital Scroll > Текст
Уловка-21 для разработки баз данных SQL Server http://digi.QQ.com 21 декабря 2009 г. 09:43 Zhongguancun Online Если вы отвечаете за проект, основанный на SQL Server, или вы новичок в SQL Server, вы можете вы столкнулись с некоторыми проблемами производительности базы данных, и эта статья предоставит вам некоторые полезные рекомендации (большинство из которых также можно использовать с другими СУБД).
Здесь я не собираюсь давать советы по использованию SQL Server и не могу предложить универсальное решение. Я просто обобщаю некоторый опыт создания хорошего дизайна. Этот опыт основан на том, чему я научился за последние несколько лет, когда я видел, как многие из одних и тех же ошибок проектирования повторялись снова и снова.
1. Знайте инструменты, которые вы используете
Не стоит недооценивать это, это самый важный момент, который я собираюсь подчеркнуть в этой статье. Возможно, вы также заметили, что многие программисты SQLServer не владеют всеми командами T-SQL и полезными инструментами, предоставляемыми SQLServer.
«Что? Я собираюсь потратить месяц на изучение команд SQL, которые никогда не буду использовать???», — можете сказать вы. Верно, вам не нужно этого делать. Но вам придется потратить выходные на изучение всех команд T-SQL. Ваша задача здесь — понять, что в будущем, когда вы будете проектировать запрос, вы будете помнить: «Кстати, вот команда, которая может полностью реализовать нужную мне функцию», поэтому зайдите в MSDN, чтобы проверить точный синтаксис эта команда.
Позвольте мне повторить еще раз: не используйте курсоры. Если вы хотите снизить производительность всей системы, они — ваш наиболее эффективный выбор. Большинство новичков используют курсоры, не осознавая, какое влияние они оказывают на производительность. Они занимают память, блокируют таблицы всеми своими странными способами и работают как улитки. И самое худшее то, что они могут сделать всю оптимизацию производительности, которую может выполнить ваш администратор базы данных, равнозначной ее невыполнению. Знаете ли вы, что каждый раз, когда вы выполняете FETCH, вы выполняете команду SELECT? Это означает, что если ваш курсор имеет 10 000 записей, он выполнит 10 000 операций SELECT! Будет намного эффективнее, если для выполнения соответствующей работы вы будете использовать набор SELECT, UPDATE или DELETE.
Новичкам обычно кажется, что использование курсоров — более привычный и удобный способ программирования, но, к сожалению, это может привести к снижению производительности. Очевидно, что общая цель SQL — это то, чего вы хотите достичь, а не то, как.
Однажды я переписал хранимую процедуру на основе курсора, используя T-SQL. В таблице было всего 100 000 записей. Исходная хранимая процедура выполнялась 40 минут, а новая хранимая процедура — всего 10 секунд. Здесь, я думаю, вы сможете увидеть, что делает некомпетентный программист! ! !
Иногда мы можем написать небольшую программу для получения и обработки данных и обновления базы данных, что иногда более эффективно. Помните: T-SQL ничего не может сделать с циклами.
Еще раз напомню: использование курсоров не дает никаких преимуществ. Я никогда не видел ничего эффективного с использованием курсоров, за исключением работы администратора базы данных.
3. Стандартизируйте таблицы данных
Почему бы не нормализовать базу данных? Вероятно, есть два оправдания: соображения производительности и явная лень. Что касается второго пункта, то за него рано или поздно придется поплатиться. Что касается производительности, вам вообще не нужно оптимизировать что-то, что не медленно. Я часто вижу, как программисты «денормализуют» базу данных, потому что причина в том, что «исходный проект был слишком медленным», но часто в результате они делают систему медленнее. СУБД предназначена для работы с каноническими базами данных, поэтому помните: проектируйте базу данных в соответствии с требованиями канонизации.
4. Не используйте SELECT *
Это нелегко сделать, я слишком хорошо это знаю, потому что сам постоянно это делаю. Однако если вы укажете нужные столбцы в SELECT, это принесет следующие преимущества:
1 Уменьшите потребление памяти и пропускную способность сети
2. Вы можете получить более безопасную конструкцию
3. Дайте оптимизатору запросов возможность прочитать все необходимые столбцы из индекса.
Страница 2. Поймите, что вы собираетесь делать с вашими данными.
Создание надежного индекса для вашей базы данных — это хорошо. Но сделать это – просто искусство. Всякий раз, когда вы добавляете индекс в таблицу, SELECT будет работать быстрее, но INSERT и DELETE будут значительно медленнее, поскольку создание и обслуживание индекса требует большого количества дополнительной работы. Очевидно, что ключ к вопросу здесь заключается в следующем: какую операцию вы хотите выполнить над этой таблицей. Эту проблему нелегко понять, особенно когда речь идет об DELETE и UPDATE, поскольку эти операторы часто содержат команды SELECT в части WHERE.
6. Не создавайте индекс по столбцу «Пол».
Во-первых, мы должны понять, как индексы ускоряют доступ к таблице. Вы можете думать об индексах как о способе разделения таблицы на основе определенных критериев. Если вы создаете индекс для столбца типа «пол», вы просто разделяете таблицу на две части: мужскую и женскую. Вы имеете дело с таблицей с 1 000 000 записей. В чем смысл этого разделения? Помните: обслуживание индексов требует много времени. При разработке индекса следуйте следующему правилу: расположите столбцы от большего к меньшему в соответствии с количеством различного содержимого, которое может содержать столбец, например: имя + провинция + пол.
7. Используйте транзакции
Пожалуйста, используйте транзакции, особенно когда запросы отнимают много времени. Если что-то пойдет не так с вашей системой, это спасет вам жизнь. Как правило, программисты с некоторым опытом поймут, что вы часто сталкиваетесь с непредсказуемыми ситуациями, которые приводят к сбою хранимой процедуры.
8. Остерегайтесь тупиков
Доступ к таблицам в определенном порядке. Если вы сначала заблокируете таблицу A, а затем заблокируете таблицу B, они должны быть заблокированы в этом порядке во всех хранимых процедурах. Если вы (случайно) сначала заблокируете таблицу B, а затем заблокируете таблицу A в хранимой процедуре, это может привести к взаимоблокировке. Если последовательность блокировки не разработана заранее, тупиковую ситуацию нелегко обнаружить.
Часто задаваемый вопрос: как быстро добавить 100 000 записей в ComboBox? Это неправильно и этого делать нельзя и не нужно. Это очень просто. Если вашему пользователю придется просмотреть 100 000 записей, чтобы найти нужную ему запись, он обязательно вас проклянет. Здесь вам нужен лучший пользовательский интерфейс, и вам нужно отображать пользователям не более 100 или 200 записей.
По сравнению с курсорами на стороне сервера курсоры на стороне клиента могут снизить нагрузку на сервер и сеть, а также сократить время блокировки.
11. Используйте запрос параметров
Иногда на техническом форуме CSDN я вижу подобные вопросы: «SELECT * FROM aWHEREa.id='A'B, возникает исключение из-за запроса с одинарной кавычкой, что мне делать?», и общий ответ: используйте два Одинарные кавычки вместо одинарных кавычек. Это неправильно. Это устраняет симптомы, а не первопричину, поскольку вы также столкнетесь с такими проблемами с другими персонажами, не говоря уже о том, что это приведет к серьезным ошибкам. Кроме того, это также помешает системе буферизации SQL Server работать должным образом. При использовании запроса параметров все эти проблемы исчезают.
12. Используйте большие базы данных при кодировании программ.
Тестовая база данных, используемая программистами при разработке, обычно не содержит большого объема данных, но зачастую конечный пользователь располагает большим объемом данных. Наш обычный подход неправильный, и причина очень проста: жесткие диски сейчас не очень дороги, но почему проблемы с производительностью не замечаются, пока они не станут необратимыми?
13. Не используйте INSERT для импорта больших объемов данных.
Пожалуйста, не делайте этого без крайней необходимости. Используйте UTS или BCP, чтобы получить гибкость и скорость одним махом.
14. Обратите внимание на проблемы с тайм-аутом
При запросе к базе данных значение по умолчанию для общей базы данных относительно невелико, например 15 секунд или 30 секунд. Некоторые запросы выполняются дольше, особенно когда объем данных в базе данных продолжает увеличиваться.
Страница 3: Не игнорируйте проблему одновременного изменения одной и той же записи.
15. Не игнорируйте проблему одновременного изменения одной и той же записи.
Иногда два пользователя одновременно изменяют одну и ту же запись. Таким образом, если последний модификатор изменяет операции предыдущего модификатора, некоторые обновления будут потеряны. Обработать эту ситуацию несложно: создайте поле временной метки, проверьте его перед записью, объедините изменения, если это разрешено, и подскажите пользователю, если возник конфликт.
16. При вставке записей в подробную таблицу не выполняйте SELECT MAX(ID) в основной таблице.
Это распространенная ошибка, которая приводит к ошибкам, когда два пользователя одновременно вставляют данные. Вы можете использовать SCOPE_IDENTITY, IDENT_CURRENT и IDENTITY. Если возможно, не используйте IDENTITY, поскольку это может вызвать проблемы при наличии триггеров (см. обсуждение здесь).
17. Не устанавливайте столбцы как NULLable.
Если возможно, вам следует избегать назначения столбцам NULL. Система выделит дополнительный байт для каждой строки столбца, допускающего значение NULL, что приведет к увеличению нагрузки на систему при запросе. Кроме того, присвоение столбцам значения NULL усложняет кодирование, поскольку эти столбцы необходимо проверять каждый раз, когда к ним осуществляется доступ.
Я не говорю, что NULL-значения являются источником проблем, хотя некоторые так думают. Я думаю, что создание столбца NULLable иногда может работать хорошо, если в ваших бизнес-правилах разрешены «нулевые данные», но использование NULLable в ситуации, подобной приведенной ниже, вызывает проблемы.
ИмяКлиента1
Адрес клиента1
Электронная почта клиента1
ИмяКлиента2
Адрес клиента2
Электронная почта клиента3
ИмяКлиента1
Адрес клиента2
Электронная почта клиента3
Если это произойдет, вам необходимо нормализовать таблицу.
18. Старайтесь не использовать тип данных TEXT.
Не используйте ТЕКСТ, если вы не имеете дело с очень большим набором данных. Потому что его нелегко запрашивать, он медленный и при неправильном использовании будет тратить много места. В общем, VARCHAR может лучше обрабатывать ваши данные.
19. Старайтесь не использовать временные таблицы
Старайтесь не использовать временные таблицы без крайней необходимости. Как правило, вместо временных таблиц можно использовать подзапросы. Использование временных таблиц приведет к увеличению нагрузки на систему, а если вы программируете с использованием COM+, это также принесет вам много проблем, поскольку COM+ использует пул соединений с базой данных, а временная таблица существует от начала до конца. SQL Server предоставляет некоторые альтернативы, такие как тип данных Table.
20. Научитесь анализировать и запрашивать
Анализатор запросов SQL Server — ваш лучший друг, с помощью которого вы сможете понять, как запросы и индексы влияют на производительность.
21. Используйте ссылочную целостность
Определение первичных ключей, ограничений уникальности и внешних ключей может сэкономить много времени.