SQL 성능 최적화는 프로그래머에게 큰 과제입니다. 왜냐하면 우리는 종종 이런 문제에 직면하기 때문입니다. 프로젝트를 개발할 때 스스로 테스트하는 기능적 경험이 정말 좋다고 생각하지만, 실제 프로젝트가 시작된 후에는 엄청난 증가로 인해 데이터 측면에서 시스템에 대한 고객 경험은 점점 더 악화되고 있습니다. 물론 프레임워크와 불합리한 코드 외에도 SQL이 최적화되지 않아 시스템이 점점 느려지는 것이 주된 이유입니다.
작은 회사에 다니다 보니 근본적인 원인을 치료하는 것보다 증상을 치료하는 것이 더 나을 때도 있는 것 같아요! 주의해야 할 몇 가지 문제가 있습니다.
1. 데이터베이스 테이블의 디자인은 합리적이어야 하며, 특히 기본 키의 디자인은 테이블의 데이터 양이 매우 클 경우 ROWID와 같이 기본 키의 디자인이 의미가 없어야 합니다. SQL Server의 GUID, Hibernate의 UUID 등 물론 일부 데이터 사전 테이블은 유연하게 처리할 수 있으므로 물리적 기본 키여야 한다는 점을 고려할 필요가 없습니다. 기본 키 설계에서는 일반적으로 복합 기본 키가 사용되지 않습니다.
2. 합리적인 인덱싱. 인덱스는 데이터 쿼리 속도를 높이는 강력한 도구이자 좋은 수단입니다. 하지만 모든 필드를 추가하지는 마세요. 색인 생성의 원리는 책의 목차와 같습니다. 책의 목차가 거의 모두 동일한 경우 목차에 따라 특정 내용을 얼마나 빨리 찾을 수 있는지 상상할 수 있습니다. ? 인덱스는 반드시 고유할 필요는 없지만 동일한 레코드가 너무 많아서는 안 됩니다. 또한, 더 많은 인덱스를 추가하면 테이블을 내보내고 다른 데이터베이스로 가져올 때 인덱스로 인해 가져오기 효율성도 감소하는 것을 볼 수 있습니다. 비정상적으로 큽니다. 따라서 지수는 양날의 검이므로 합리적으로 적용해야 합니다.
3. 인터넷에서 SQL 최적화에 관한 매우 전문적인 기사를 본 적이 있지만 내 프로젝트에서는 이러한 기사를 사용할 수 없었던 것 같습니다. 대신, 나는 프로젝트를 진행하면서 몇 가지 기본 원칙을 계속해서 실험하고 발견했습니다. 개인적으로 SQL 최적화의 원칙은 쿼리 범위를 최대한 좁히는 것 밖에 없다고 생각합니다. 이렇게 하면 확실히 효율성이 향상되고, 우리가 작성한 SQL은 오라클 자체에서 최적화할 수 있기 때문에 우리가 해야 할 일은 다음과 같습니다. 이렇게 말하면 인덱싱은 쿼리 속도를 높이는 강력한 도구라고 다들 생각하실 텐데요. 사실 그것도 수단일 뿐이고, 쿼리 범위를 좁히는 원리에서도 유래합니다. .
최적화가 필요한 SQL의 대부분은 다중 테이블 조인 쿼리이며, 다중 테이블 조인에는 수평 조인과 수직 조인도 포함됩니다. 수평 연결은 일반적으로 두 테이블의 필드 구조가 기본적으로 동일하며 한 테이블의 일부 데이터 레코드를 다른 테이블의 일부 레코드, 즉 Rows+Rows로 변경해야 함을 의미합니다. 수직 연결이란 테이블 A에서 쿼리할 필드 일부와 B 테이블에서 쿼리할 필드를 가져온 다음, 테이블 A와 B에서 가져온 테이블을 공통 부분인 Columns+Columns를 사용하여 수직으로 연결하는 것을 의미합니다.
수평 조인 문: tableA에서 a.column1,a.column2를 선택합니다. 공용체는 모두 tableB에서 b.column1,b.column2를 선택합니다.
주의할 점은 가로 연결 시 컬럼 개수가 동일해야 하며, 해당 필드 컬럼의 데이터 타입도 동일해야 한다는 점입니다. 실제로 유니온할 테이블은 다른 테이블의 복사본과 정확히 동일하다고 생각할 수 있습니다. 병합하려는 열에 다른 열이 있거나 열이 전혀 없으면 다음 방법을 사용할 수 있습니다.
dept1에서 d.dname,d.loc 선택 d Union all dept e에서 '' dname, e.loc 선택, "'' dname"을 보면 대체 항목을 쉽게 찾을 수 있습니다. 대신 빈 문자열을 사용하세요. 필드가 없으므로 병합할 수 있습니다.
수직 조인 문: tableA에서 a.column1,a.column2를 선택합니다. 완전 외부 조인 a.aid=b.bid에서 tableB에서 b.column3,b.column4를 선택합니다. 여기서... 이것은 완전 외부 조인 형식입니다. 이 속도는 실제로 매우 빠르지만 전혀 보고 싶지 않은 결과 행이 있기 때문에 쿼리가 마음에 들지 않을 수 있습니다. 일반적인 상황에서는 왼쪽 외부 조인과 오른쪽 외부 조인을 더 많이 사용합니다. 둘의 차이점은 왼쪽 외부 조인은 주로 on 이후 왼쪽의 조인 필드에 해당하는 테이블을 기반으로 하고 오른쪽 외부 조인은 정반대라는 점입니다. 물론 왼쪽 조인, 오른쪽 조인을 사용할 수도 있습니다. 사용하는 동안에도 외부 연결이 상대적으로 더 빠르다는 것을 알았습니다.
수직 연결 쿼리의 효율성을 높이기 위한 방법은 쿼리를 중첩하는 것입니다. 다음은 프로젝트의 실제 예입니다.
c.customerid,c.receivedmoney,c.tollcollector,c.receiveddate,c.yearmonth,c.receivedlatefee를 선택하고,
c.receivedfee,c.receivedappend,c.jmman,c.jmmoney,c.name,d.chargeint from
(a.customerid,a.receivedmoney,a.tollcollector,a.receiveddate,a.yearmonth,a.receivedlatefee,
a.receivedfee,a.receivedappend,a.jmman,a.jmmoney,b.이름
(rf.customerid,rf.receivedmoney,rf.tollcollector,rf.receiveddate,rf.yearmonth,rf.receivedlatefee,
rf.receivedfee,rf.receivedappend,rf.jmman,rf.jmmoney from sf_receivedfee rf 여기서
rf.electriccompanyid='1000000001' 및 rf.dealsign=0 및 rf.yearmonth in(200811,200901,200903,200804,200805,200806,200807)
및 rf.customerid=1000052545) 왼쪽 외부 조인(xt_employee xe에서 xe.employeeid,xe.name 선택) a.tollcollector=b.employeeid의 b)
c 왼쪽 외부 조인(sf_chargeprotocol cp에서 cp.chargeint,cp.customerid 선택, 여기서 cp.customerid=1000052545) d
c.customerid=d.customerid에서
이 예에서는 먼저 거의 동일한 조건을 사용하여 각 테이블에서 필요한 레코드를 필터링한 다음 레코드를 병합하는 것을 볼 수 있습니다. 실제 사용에서는 이것이 직접 링크 쿼리보다 거의 60배 빠릅니다. 보기 흉하고 읽기 어렵지만 SQL 성능 문제를 해결합니다. 사용하는 원리는 여전히 범위를 좁힌 다음 연결 쿼리를 수행하는 것입니다. 연결한 다음 필터링하면 두 테이블을 병합한 다음 조건에 따라 데이터를 가져오는 것과 같습니다.