원리:첫 번 째 단계:응용 프로그램 은 SQL 문 구 를 서버 에 보 내 서 실행 합 니 다.데이터 계층 에서 SQL 문 구 를 실행 할 때 응용 프로그램 은 해당 데이터베이스 서버 에 연결 하여 SQL 문 구 를 서버 에 보 냅 니 다.두 번 째 단계:서버 에서 요청 한 SQL 문 구 를 분석 합 니 다.1:SQL 계획 캐 시,검색 분석 기 를 자주 사용 하 는 친구 들 은 이러한 사실 을 알 고 있 습 니 다.검색 어 는 처음 실 행 될 때 매우 긴 시간 이 필요 하지만,즉시 또는 일정 시간 내 에 같은 문 구 를 실행 하면 짧 은 시간 내 에 검색 결 과 를 되 돌려 줍 니 다.원인:1):서버 는 조회 요청 을 받 은 후 바로 데이터베이스 에 가서 조회 하지 않 고 데이터베이스 에 있 는 계획 캐 시 에서 해당 하 는 실행 계획 이 있 는 지 찾 습 니 다.존재 하면 이미 컴 파일 된 실행 계획 을 직접 호출 하여 실행 계획 의 컴 파일 시간 을 절약 합 니 다.2):검색 한 줄 이 데이터 버퍼 저장 소 에 존재 한다 면 물리 파일 을 조회 하지 않 고 캐 시 에서 데 이 터 를 가 져 옵 니 다.그러면 메모리 에서 데 이 터 를 가 져 오 는 것 이 하 드 디스크 에서 데 이 터 를 읽 는 것 보다 훨씬 빠 르 고 조회 효율 을 높 입 니 다.데이터 버퍼 저장 소 는 뒤에서 언급 합 니 다.2:SQL 계획 캐 시 에 대응 하 는 실행 계획 이 없 으 면 서버 는 먼저 사용자 가 요청 한 SQL 문 구 를 문법 적 으로 검증 합 니 다.문법 오류 가 있 으 면 서버 는 조회 작업 을 끝내 고 해당 하 는 오류 정 보 를 되 돌려 프로그램 을 호출 합 니 다.메모:이 때 돌아 오 는 오류 정보 에는 기본 적 인 문법 오류 정보 만 포 함 됩 니 다.예 를 들 어 select 를 selec 로 쓰 는 등 오류 정보 에 목록 에 없 는 열 이 포함 되 어 있 으 면 서버 에서 검사 하지 않 습 니 다.문법 검증 일 뿐 의미 가 다음 단계 에 진행 되 고 있 는 지 여부 입 니 다.3:문법 이 일치 하면 그 의미 가 정확 한 지 검증 하기 시작한다.예 를 들 어 표 명,열 명,저장 과정 등 데이터베이스 대상 이 진정 으로 존재 하 는 지 확인 하고 존재 하지 않 는 것 을 발견 하면 응용 프로그램 에 잘못 보고 하고 조 회 를 끝 낸다.4:다음은 대상 의 분석 자 물 쇠 를 얻 는 것 입 니 다.우 리 는 시 계 를 조회 할 때 먼저 서버 가 이 대상 에 자 물 쇠 를 추가 합 니 다.이것 은 데이터 의 통일 성 을 확보 하기 위해 서 입 니 다.자 물 쇠 를 추가 하지 않 으 면 데이터 가 삽입 되 지만 자 물 쇠 를 추가 하지 않 은 이유 로 조 회 는 이미 이 기록 을 읽 었 고 어떤 삽입 은 업무 의 실패 로 인해 스크롤 백 되 어 더러 운 읽 기 현상 이 발생 할 수 있 습 니 다.5:다음은 데이터베이스 사용자 권한 에 대한 검증 입 니 다.SQL 구문 문법,의미 가 모두 정확 합 니 다.이때 반드시 조회 결 과 를 얻 을 수 있 는 것 은 아 닙 니 다.만약 에 데이터베이스 사용자 가 해당 하 는 접근 권한 이 없 으 면 서버 는 권한 이 부족 한 오 류 를 응용 프로그램 에 보고 합 니 다.조금 큰 프로젝트 에 여러 개의 데이터 베이스 연결 문자열 이 포함 되 어 있 습 니 다.이러한 데이터베이스 사용 자 는 서로 다른 권한 을 가지 고 있 습 니 다.어떤 것 은 읽 기 전용 권한 이 고,어떤 것 은 읽 기 전용 권한 이 며,어떤 것 은 읽 기 전용 권한 이 며,서로 다른 조작 에 따라 서로 다른 사용 자 를 선택 하여 실행 할 수 있 습 니 다.조금 만 주의 하지 않 으 면 SQL 문 구 를 아무리 완벽 하 게 써 도 소 용이 없습니다.6:해석 의 마지막 단 계 는 최종 집행 계획 을 확정 하 는 것 이다.문법,의미,권한 이 모두 검 증 된 후에 서버 는 바로 결 과 를 되 돌려 주지 않 고 SQL 을 최적화 시 켜 서로 다른 조회 알고리즘 을 선택 하여 가장 효율 적 인 형식 으로 응용 프로그램 에 되 돌려 줍 니 다.예 를 들 어 표 공동 조 회 를 할 때 서버 는 비용 비용 에 따라 최종 적 으로 hash join,merge join,loop join 을 사용 하 는 지,어떤 색인 을 사용 하 는 것 이 더 효율 적 인지 등 을 결정 하지만 자동화 최적화 가 유한 하 다.효율 적 인 조회 SQL 을 쓰 려 면 자신의 SQL 조회 문 구 를 최적화 해 야 한다.실행 계획 이 확정 되면 이 실행 계획 을 SQL 계획 캐 시 에 저장 하고 다음 에 같은 실행 요청 이 있 을 때 계획 캐 시 에서 직접 가 져 와 실행 계획 을 다시 컴 파일 하지 않도록 합 니 다.세 번 째 단계:문장 집행.서버 가 SQL 문 구 를 분석 한 후에 야 서버 는 이 문구 가 도대체 무슨 뜻 을 표 시 했 는 지 알 수 있 고 그 다음 에 야 SQL 문 구 를 진정 으로 실행 할 수 있 습 니 다.이 때 두 가지 상황 으로 나 뉜 다.1)검색 어 에 포 함 된 데이터 줄 이 데이터 버퍼 저장 소 에 읽 혔 다 면 서버 는 데이터 버퍼 저장 소 에서 데 이 터 를 직접 읽 어 응용 프로그램 에 되 돌려 주 고 물리 적 파일 에서 읽 지 않도록 조회 속 도 를 높 인 다.2):데이터 줄 이 데이터 버퍼 저장 소 에 없 으 면 물리 파일 에서 기록 을 읽 어 응용 프로그램 에 되 돌려 주 고 데이터 줄 을 데이터 버퍼 저장 소 에 기록 하여 다음 에 사용 할 수 있 습 니 다.설명:SQL 캐 시 는 여러 가지 로 나 뉘 어 있 습 니 다.여기 서 관심 이 있 는 친 구 는 검색 해 볼 수 있 습 니 다.가끔 은 캐 시가 존재 하기 때문에 우 리 는 최 적 화 된 결 과 를 바로 알 아 보기 어렵 습 니 다.두 번 째 실행 은 캐 시가 존재 하기 때문에 매우 빠 릅 니 다.그래서 보통 버퍼 를 제거 한 다음 에 전후의 성능 표현 을 최적화 합 니 다.DBCC DROPCLEANBUFFERS 는 버퍼 에서 모든 버퍼 를 삭제 합 니 다.DBCC FREEPROCACHE 는 프로 세 스 캐 시 에서 모든 요 소 를 삭제 합 니 다.DBCC FREESYSTEMCACHE 는 모든 캐 시 에서 사용 하지 않 은 캐 시 항목 을 방출 합 니 다.SQL Server 2005 데이터베이스 엔진 은 현재 항목 에 사용 할 수 있 도록 미리 배경 에서 사용 되 지 않 은 캐 시 항목 을 정리 합 니 다.단,이 명령 을 사용 하면 모든 캐 시 에서 사용 하지 않 은 항목 을 수 동 으로 삭제 할 수 있 습 니 다.이것 은 SQL 캐 시 에 미 치 는 영향 만 기본적으로 제거 할 수 있 습 니 다.현재 캐 시 를 완전히 제거 하 는 방안 이 없 는 것 같 습 니 다.있 으 면 가르쳐 주 십시오.실행 순서:1.FROM 자구 가 초기 결과 집합 을 되 돌려 줍 니 다.2.WHERE 자 구 는 검색 조건 에 만족 하지 않 는 줄 을 제외한다.3.GROUP BY 자 구 는 선 택 된 줄 을 GROUP BY 자구 의 각각 유일 하 게 값 이 있 는 그룹 에 수집 합 니 다.4.목록 에서 지정 한 집합 함 수 를 선택 하면 각 그룹의 집합 값 을 계산 할 수 있 습 니 다.5.그 밖 에 HAVING 자 구 는 검색 조건 을 만족 시 키 지 못 하 는 줄 을 제외한다.6.모든 표현 식 계산 하기;7.orderby 를 사용 하여 결과 집합 을 정렬 합 니 다.8.검색 할 필드 를 찾 습 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
