탐색 · 홈페이지로 설정 · 즐겨찾기에 추가 · 모바일 Tencent · Tencent 홈페이지 뉴스 블로그 포럼 댓글 금융 증권 홍콩 주식 자금 엔터테인먼트 스타 영화 음악 스포츠 NBA 축구 종합 자동차 부동산 가전 기술 디지털 모바일 다운로드 여성 감정 육아 패션 쇼핑 여행 독서 원본 교육 해외 게임 애니메이션 애니메이션 별자리 비디오 라이브 사진 엑스포 자선 어린이 새로운 인기 인기 중국 금 디스크 다채로운 패션과 사치품의 세계를 방문하세요 전국 베스트 셀러 휴대폰 순위 목록을 따라 오늘 생일을 맞은 유명 인사를 확인하세요. 귀하의 위치: Tencent. 홈 페이지 > 기술과 디지털 > 디지털 스크롤 뉴스 > 텍스트
SQL Server 데이터베이스 개발을 위한 캐치-21 http://digi.QQ.com 2009년 12월 21일 09:43 Zhongguancun Online SQL Server 기반 프로젝트를 담당하고 있거나 SQL Server를 처음 사용하는 경우 다음을 수행할 수 있습니다. 일부 데이터베이스 성능 문제에 직면하게 될 경우 이 문서에서는 몇 가지 유용한 지침을 제공합니다(대부분은 다른 DBMS에서도 사용할 수 있음).
여기서는 SQL Server 사용에 대한 팁을 소개하지도 않고, 만병통치약을 제공할 수도 없습니다. 제가 하는 일은 좋은 디자인을 구성하는 방법에 대한 몇 가지 경험을 요약하는 것입니다. 이 경험은 지난 몇 년 동안 동일한 설계 실수가 반복해서 반복되는 것을 많이 보아왔고 제가 배운 것에서 비롯되었습니다.
1. 사용하는 도구를 알아두세요
이것을 과소평가하지 마십시오. 이것이 제가 이 글에서 설명할 가장 중요한 사항입니다. 아마도 많은 SQLServer 프로그래머가 모든 T-SQL 명령과 SQLServer에서 제공하는 유용한 도구를 마스터하지 못한다는 사실을 보셨을 것입니다.
"뭐라구요? 절대 사용하지도 않을 SQL 명령을 배우느라 한 달을 낭비하게 될 것 같아요???"라고 말할 수도 있습니다. 그렇죠, 이렇게 할 필요는 없습니다. 하지만 모든 T-SQL 명령을 살펴보려면 주말을 보내야 합니다. 여기서 여러분의 임무는 나중에 쿼리를 디자인할 때 "그런데, 여기 내가 필요한 기능을 완전히 달성할 수 있는 명령이 있습니다."라는 내용을 기억하게 될 것임을 이해하는 것입니다. 따라서 MSDN으로 이동하여 쿼리의 정확한 구문을 확인하세요. 이 명령 .
다시 반복하겠습니다. 커서를 사용하지 마세요. 전체 시스템의 성능을 파괴하고 싶다면 이것이 가장 효과적인 첫 번째 선택입니다. 대부분의 초보자는 커서가 성능에 미치는 영향을 인식하지 못한 채 커서를 사용합니다. 그들은 메모리를 차지하고, 이상한 방식으로 테이블을 잠그고, 달팽이처럼 작동합니다. 그리고 최악의 상황은 DBA가 수행할 수 있는 모든 성능 최적화를 수행하지 않는 것과 동일하게 만들 수 있다는 것입니다. FETCH를 실행할 때마다 SELECT 명령이 실행된다는 것을 알고 계십니까? 이는 커서에 10,000개의 레코드가 있으면 10,000개의 SELECT를 수행한다는 의미입니다! 해당 작업을 완료하기 위해 SELECT, UPDATE 또는 DELETE 세트를 사용하면 훨씬 더 효율적입니다.
초보자들은 일반적으로 커서를 사용하는 것이 더 친숙하고 편안한 프로그래밍 방법이라고 생각하지만, 불행히도 이로 인해 성능이 저하될 수 있습니다. 분명히 SQL의 전반적인 목적은 달성하고자 하는 것이지 방법이 아닙니다.
한번은 T-SQL을 사용하여 커서 기반 저장 프로시저를 다시 작성한 적이 있습니다. 테이블에는 100,000개의 레코드만 있었습니다. 원래 저장 프로시저는 완료하는 데 40분이 걸렸지만 새 저장 프로시저는 10초밖에 걸리지 않았습니다. 여기서는 무능한 프로그래머가 하는 일을 볼 수 있어야 한다고 생각합니다! ! !
때로는 데이터를 검색 및 처리하고 데이터베이스를 업데이트하는 작은 프로그램을 작성할 수 있는데, 이는 때로는 더 효율적입니다. 기억하세요: T-SQL은 루프에 대해 아무 것도 할 수 없습니다.
다시 한 번 상기시켜 드리겠습니다. 커서를 사용해도 이점이 없습니다. DBA 작업을 제외하고는 커서를 사용하여 효과적으로 수행되는 작업을 본 적이 없습니다.
3. 데이터 테이블 표준화
데이터베이스를 정규화하지 않는 이유는 무엇입니까? 아마도 두 가지 변명이 있을 것입니다. 성능상의 이유와 순전한 게으름입니다. 두 번째 요점은 조만간 비용을 지불해야합니다. 그리고 성능에 관해서는 전혀 느리지 않은 것을 최적화할 필요가 없습니다. 나는 종종 프로그래머들이 "원래 디자인이 너무 느리기 때문에" 데이터베이스를 "비정규화"하는 것을 보지만, 그 결과 시스템이 느려지는 경우가 많습니다. DBMS는 정식 데이터베이스를 처리하도록 설계되었으므로 정규화 요구 사항에 따라 데이터베이스를 설계해야 한다는 점을 기억하십시오.
4. SELECT *를 사용하지 마십시오
나는 그것을 너무 잘 알고 있기 때문에 쉽지 않습니다. 왜냐하면 나는 항상 그것을 스스로하기 때문입니다. 그러나 SELECT에 필요한 열을 지정하면 다음과 같은 이점이 있습니다.
1 메모리 소비 및 네트워크 대역폭 감소
2 좀 더 안전한 디자인을 얻을 수 있습니다
3 쿼리 최적화 프로그램에 인덱스에서 필요한 모든 열을 읽을 수 있는 기회를 제공합니다.
2페이지: 데이터로 무엇을 할 것인지 이해하기
데이터베이스에 대한 강력한 색인을 만드는 것은 좋은 일입니다. 그러나 이것을 하는 것은 단지 예술일 뿐입니다. 테이블에 인덱스를 추가할 때마다 SELECT는 더 빨라지지만 인덱스를 생성하고 유지하려면 많은 추가 작업이 필요하기 때문에 INSERT 및 DELETE는 상당히 느려집니다. 분명히 여기서 질문의 핵심은 이 테이블에서 어떤 종류의 작업을 수행하려는지입니다. 특히 DELETE 및 UPDATE의 경우 이러한 문에는 WHERE 부분에 SELECT 명령이 포함되어 있는 경우가 많기 때문에 이 문제를 파악하기가 쉽지 않습니다.
6. "성별" 열에 인덱스를 생성하지 마세요.
먼저 인덱스가 테이블에 대한 액세스 속도를 높이는 방법을 이해해야 합니다. 인덱스는 특정 기준에 따라 테이블을 나누는 방법으로 생각할 수 있습니다. "성별"과 같은 열에 인덱스를 생성하면 테이블을 남성과 여성의 두 부분으로 나누는 것입니다. 1,000,000개의 레코드가 있는 테이블을 다루고 있습니다. 이 구분의 의미는 무엇입니까? 기억하세요: 인덱스를 유지하는 데는 시간이 많이 걸립니다. 색인을 디자인할 때 다음 규칙을 따르십시오. 이름 + 지방 + 성별과 같이 열에 포함될 수 있는 다양한 콘텐츠 수에 따라 가장 많은 것부터 가장 작은 것까지 열을 정렬하십시오.
7. 거래 이용
특히 쿼리에 시간이 많이 걸리는 경우 트랜잭션을 사용하세요. 시스템에 문제가 발생하면 생명을 구할 수 있습니다. 일반적으로 어느 정도 경험이 있는 프로그래머는 저장 프로시저의 충돌을 일으키는 예측할 수 없는 상황이 자주 발생한다는 것을 이해합니다.
8. 교착상태에 주의하라
특정 순서로 테이블에 액세스합니다. 테이블 A를 먼저 잠근 다음 테이블 B를 잠그면 모든 저장 프로시저에서 이 순서대로 테이블을 잠가야 합니다. (실수로) 테이블 B를 먼저 잠근 다음 저장 프로시저에서 테이블 A를 잠그면 교착 상태가 발생할 수 있습니다. 잠금 순서를 사전에 구체적으로 설계하지 않으면 교착 상태를 감지하기가 쉽지 않습니다.
자주 묻는 질문은 다음과 같습니다. 100,000개의 레코드를 ComboBox에 빠르게 추가하려면 어떻게 해야 합니까? 이것은 옳지 않으며 그렇게 할 수도 없고 할 필요도 없습니다. 매우 간단합니다. 사용자가 필요한 기록을 찾기 위해 100,000개의 기록을 검색해야 한다면 그는 분명히 당신을 저주할 것입니다. 여기에서 필요한 것은 더 나은 UI이며 사용자에게 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. 열을 NULL 가능으로 설정하지 마세요.
가능하다면 열을 NULL 가능으로 설정하지 않는 것이 좋습니다. 시스템은 NULL 가능 열의 각 행에 추가 바이트를 할당하므로 쿼리 시 더 많은 시스템 오버헤드가 발생합니다. 또한 열을 NULL 가능으로 만들면 해당 열에 액세스할 때마다 확인해야 하므로 코딩이 복잡해집니다.
일부 사람들은 그렇게 생각하지만 NULL이 문제의 원인이라고 말하는 것은 아닙니다. 비즈니스 규칙에 "null 데이터"가 허용된 경우 열을 NULL 가능으로 만드는 것이 때때로 잘 작동할 수 있다고 생각하지만, 아래와 같은 상황에서 NULL 가능을 사용하면 문제가 발생합니다.
고객 이름1
고객주소1
고객이메일1
고객 이름2
고객주소2
고객이메일3
고객 이름1
고객주소2
고객이메일3
이런 일이 발생하면 테이블을 정규화해야 합니다.
18. TEXT 데이터 유형을 사용하지 마십시오.
매우 큰 데이터 세트를 처리하는 경우가 아니면 TEXT를 사용하지 마십시오. 쿼리하기가 쉽지 않고 속도가 느리며 제대로 사용하지 않으면 많은 공간을 낭비하게 되기 때문입니다. 일반적으로 VARCHAR이 데이터를 더 잘 처리할 수 있습니다.
19. 임시 테이블을 사용하지 마세요.
반드시 필요한 경우가 아니면 임시 테이블을 사용하지 마십시오. 일반적으로 임시 테이블 대신 하위 쿼리를 사용할 수 있습니다. 임시 테이블을 사용하면 시스템 오버헤드가 발생하고, COM+로 프로그래밍하는 경우에도 많은 문제가 발생합니다. COM+는 데이터베이스 연결 풀을 사용하고 임시 테이블이 처음부터 끝까지 존재하기 때문입니다. SQL Server는 테이블 데이터 형식과 같은 몇 가지 대안을 제공합니다.
20. 분석하고 쿼리하는 방법을 배우십시오.
SQL Server 쿼리 분석기는 쿼리와 인덱스가 성능에 어떤 영향을 미치는지 이해할 수 있는 가장 좋은 친구입니다.
21. 참조 무결성을 사용하세요
기본 키, 고유 제약 조건 및 외래 키를 정의하면 많은 시간을 절약할 수 있습니다.