최 적 화 는 복잡 한 임무 이다.왜냐하면 그것 은 최종 적 으로 전체 시스템 에 대한 이해 가 필요 하기 때문이다.당신 의 시스템/응 용 된 작은 지식 으로 국부 적 최 적 화 를 하 는 것 이 가능 할 때,당신 은 당신 의 시스템 을 더욱 최적화 시 키 려 고 할 수록,당신 은 그것 도 많 음 을 알 아야 한다. 따라서 이 장 에 서 는 MySQL 을 최적화 하 는 다양한 방법의 예 를 설명 하고 제시 하려 고 합 니 다.그러나 항상 어떤(점점 어려워 지 는)방법 은 시스템 이 더 빠 른 방법 으로 남 겨 두 고 하 는 것 을 기억 하 세 요. 시스템 을 더욱 빠르게 하기 위해 서 가장 중요 한 부분 은 당연히 기본 적 인 디자인 이다.당신 도 당신 의 시스템 이 이런 일 을 할 것 이라는 것 을 알 아야 한다.그것 이 바로 당신 의 병목 이다. 가장 흔히 볼 수 있 는 병목 은: 디스크 길 찾기.디스크 는 데 이 터 를 찾 는 데 시간 이 걸 리 고 1999 년 현대 디스크 의 평균 시간 은 보통 10ms 보다 작 기 때문에 이론 적 으로 우 리 는 약 1 초 동안 길 을 찾 을 수 있다. 1000 회.이 시간 에 새 디스크 로 높이 는 것 은 매우 느 리 고 표 하 나 를 최적화 하기 어렵다.최적화 하 는 방법 은 데 이 터 를 여러 디스크 에 분산 시 키 는 것 이다. 디스크 가 우리 가 데 이 터 를 읽 어야 할 정확 한 위치 에 있 을 때 디스크 읽 기/쓰기.1999 년 현대 에 한 디스크 로 10-20Mb/s 와 유사 하 게 전송 되 었 습 니 다.이 는 여러 디스크 에서 병렬 적 으로 읽 을 수 있 기 때문에 길 찾기 가 더욱 쉽 습 니 다. CPU 주기 입 니 다.우리 가 데 이 터 를 메모리 에 읽 을 때(또는 그것 이 이미 거기에 있다 면)우 리 는 그것 을 처리 하여 우리 의 결 과 를 달성 해 야 합 니 다.우리 가 상대 적 으로 메모리 가 작은 시 계 를 가지 고 있 을 때 이것 은 가장 흔히 볼 수 있 는 제한 요소 이지 만 작은 시계 속 도 를 사용 하 는 것 은 문제 가 되 지 않 습 니 다. 메모리 대역 폭.CPU 가 cpu 캐 시 에 적합 한 데 이 터 를 초과 해 야 할 때 캐 시 대역 폭 은 메모리 의 병목 이 됩 니 다.이것 은 대부분의 시스템 에 흔 하지 않 은 병목 이지 만 알 아야 합 니 다. 10.2 시스템/컴 파일 할 때 와 시작 매개 변 수 를 조절 하 는 것 은 우 리 는 시스템 급 의 것 으로 시작 합 니 다.이러한 결정 들 은 아주 일찍 이 루어 졌 기 때 문 입 니 다.다른 상황 에서 이 부분 을 빨리 조회 하면 충분 할 것 입 니 다.큰 수확 에 중요 하지 않 지만 이 단계 에서 얼마나 많은 것 을 얻 었 는 지 에 대한 느낌 이 항상 좋 습 니 다. 사용 하 는 결 성 OS 가 정말 중요 합 니 다!다 중 CPU 를 최대한 사용 하기 위해 서 는 Solaris(스 레 드 가 잘 작 동 하기 때 문)나 Linux(2.2 권 의 핵심 이 좋 고 SMP 지원 이 확실 하기 때 문)를 사용 해 야 합 니 다.또한 32 비트 기기 에 서 는 2G 의 파일 크기 제한 이 부족 합 니 다.새로운 파일 시스템 이 풀 렸 을 때( XFS ),조만간 수정 되 기 를 바 랍 니 다. 우 리 는 많은 플랫폼 에서 MySQL 을 생산 하지 않 았 기 때문에,우 리 는 당신 이 그것 을 선택 하기 전에 당신 이 실행 하고 자 하 는 플랫폼 을 테스트 하 라 고 충고 합 니 다. 기타 제안: RAM 이 충분 하 다 면 모든 교환 장 치 를 삭제 할 수 있 습 니 다.일부 운영 체 제 는 메모리 가 남아 있 더 라 도 SWAP 장 치 를 사용 할 것 입 니 다. 사용--skip -locking 의 MySQL 옵션 은 외부 잠 금 을 피 합 니 다.MySQL 기능 에 영향 을 주지 않 습 니 다.한 서버 에서 만 실행 된다 면 myisamchk 를 실행 하기 전에 서버(또는 관련 부분 잠 금)를 멈 추 는 것 을 기억 하 십시오.일부 시스템 에 서 는 이 스위치 가 강제 적 입 니 다.외부 잠 금 이 어떠한 상황 에서 도 작 동 하지 않 기 때 문 입 니 다.MIT-pthreads 로 컴 파일 할 때-- skip-locking 옵션 은(on)을 여 는 것 이 부족 합 니 다.flock()이 모든 플랫폼 에서 MIT-pthreads 에 의 해 충분히 지원 되 지 않 았 기 때 문 입 니 다.유일한 경 우 는 같은 데이터 에 대해 MySQL 서버(클 라 이언 트 가 아 닌)를 실행 할 수 없다 는 것 입 니 다.-skip-locking 을 사용 할 수 없 을 때,그렇지 않 으 면 먼저 지우 지 않 거나 my sqld 서버 의 표를 잠 그 고 my isamchk 를 실행 할 수 있 습 니 다.LOCK 을 사용 할 수 있 습 니 다. TABLES/ UNLOCK TABLES,사용 하고 있어 도--skip-locking. 컴 파일 과 링크 는 MySQL 의 속도 에 어떻게 영향 을 줍 니까? 대부분의 다음 테스트 는 Linux 에서 MySQL 기준 으로 진행 되 지만 다른 운영 체제 와 작업 부하 에 대해 지 시 를 해 야 합 니 다. -static 링크 를 사용 할 때 가장 빠 른 실행 가능 한 파일 을 얻 을 수 있 습 니 다.TCP/IP 대신 유 닉 스 소켓 을 사용 하여 데이터 베 이 스 를 연결 하 는 것 도 좋 은 성능 을 제공 할 수 있 습 니 다. Linux 에 서 는 pgcc 와-O6 로 컴 파일 할 때 가장 빠 른 코드 를 얻 을 수 있 습 니 다.이 옵션 들 을 사용 하기 위해"sql"을 컴 파일 합 니 다."Ycc.cc",약 200 M 메모리 가 필요 합 니 다.왜냐하면 gcc/pgcc 는 모든 함수(inline)를 삽입 하기 위해 많은 메모리 가 필요 합 니 다.MySQL 을 설정 할 때 도 libstdc+라 이브 러 리 를 포함 하지 않도록 CXX=gcc 를 설정 해 야 합 니 다. 좋 은 컴 파일 러 나 좋 은 컴 파일 러 옵션 만 사용 하면 응용 프로그램 에서 10-30%의 속 도 를 얻 을 수 있 습 니 다.SQL 서버 를 직접 컴 파일 하면 특히 중요 합 니 다! Intel 에 서 는 pgcc 나 Cygnus 를 사용 해 야 합 니 다. CodeFusion 컴 파일 러 가 최대 속 도 를 얻 었 습 니 다.우 리 는 이미 새로운 것 을 테스트 했 습 니 다. Fujitsu 컴 파일 러,하지만 MySQL 컴 파일 을 최적화 하기 위해 서 는 아직 충분 하지 않 습 니 다. 여 기 는 우리 가 만 든 측량 표 이다. 만약 당신 이-O6 로 pgcc 를 사용 하고 모든 것 을 컴 파일 한다 면,my sqld 서버 는 gcc 를 사용 하 는 것 보다 11%빠 릅 니 다(문자열 99 버 전). 동적 으로 연결(-static 없 음)하면 13%느 려 집 니 다.동적 으로 연 결 된 MySQL 라 이브 러 리 를 사용 할 수 있 습 니 다.서버 만 성능 이 관건 입 니 다. 유 닉 스 소켓 이 아 닌 TCP/IP 를 사용 하면 결 과 는 7.5%느 립 니 다. 썬 SPARCstation 10 위,gcc 2.7.3 은 Sun 보다 Pro C++ 4.2 빠 른 13%. Solaris 에서 2.5.1 에서 단일 프로세서 에서 MIT-pthreads 는 원생 라인 을 가 진 Solaris 보다 8-12%느 립 니 다.더 많은 부하/cpus 로 차이 가 커 져 야 합 니 다. TcX 가 제공 하 는 MySQL-linux 의 배 포 는 pgcc 로 컴 파일 되 고 정적 링크 입 니 다. 앞에서 말 했 듯 이 디스크 길 찾기 는 성능 의 큰 병목 입 니 다.데이터 가 증가 하기 시작 하면 캐 시 가 불가능 해 집 니 다.이 문 제 는 점점 뚜렷 해 집 니 다.큰 데이터 베 이 스 는 어느 정도 무 작위 로 데 이 터 를 액세스 해 야 합 니 다.최소한 한 번 의 디스크 길 찾기 를 통 해 읽 고 몇 번 의 디스크 길 찾기 를 기록 할 수 있 습 니 다.이 문 제 를 최소 화하 기 위해 서 는낮은 길 찾기 시간 이 있 는 디스크 를 사용 합 니 다. 사용 가능 한 디스크 축의 수 를 늘 리 고 길 찾기 비용 을 줄 이기 위해 서 기호 연결 파일 을 서로 다른 디스크 나 디스크 로 분할 하 는 것 이 가능 합 니 다. 기호 연결 을 사용 하 는 것 은 색인/데이터 파일 기 호 를 정상 적 인 데이터 디 렉 터 리 에서 다른 디스크 로 연결 하 는 것 을 의미 합 니 다.(그것 도 분할 할 수 있 습 니 다)길 찾기 와 읽 기 시간 이 더 좋 습 니 다.(디스크 가 다른 일 에 사용 되 지 않 는 다 면)10.2.2.1 참조. 데이터베이스 와 표 의 심 볼 릭 링크 를 사용 합 니 다. 분할 분할 은 디스크 가 많 고 첫 번 째 디스크 에 첫 번 째 디스크 를 두 고 두 번 째 디스크 에 두 고 두 번 째 디스크 에 두 는 것 을 의미 합 니 다. 블록 mod number_of_disks)디스크 등등.이것 은 정상 적 인 데이터 가 분할 크기(또는 완벽 하 게 배열)보다 크 면 좋 은 성능 을 얻 을 수 있 음 을 의미 합 니 다.분할 이 OS 와 분할 크기 에 의존 하 는 지 주의 하 십시오.따라서 서로 다른 분할 크기 로 응용 프로그램 순 서 를 테스트 합 니 다.10.8 참조. 자신의 기준 을 사용 하 십시오.분할 속도 차 이 는 매개 변수 에 의존 합 니 다.매개 변수 와 디스크 의 수량 을 어떻게 분할 하 느 냐 에 따라 수량 급 의 차 이 를 얻 을 수 있 습 니 다.무 작위 또는 순서 액세스 최적화 로 선택해 야 합 니 다. 믿 을 수 있 도록 습격 RAID 를 사용 하고 싶 을 수도 있 습 니 다. 0+1(분할+미 러),하지만 이 경우 N 드라이브 의 데 이 터 를 저장 하기 위해 2*N 드라이브 가 필요 합 니 다.돈 이 있다 면 가장 좋 은 선택 일 수 있 습 니 다!그러나 당신 은 그것 을 효율적으로 처리 하기 위해 볼 륨 관리 소프트웨어 투 자 를 해 야 할 수도 있 습 니 다. 좋 은 선택 은 조금 중요 한 데이터(재생 가능)에 RAID 가 존재 하도록 하 는 것 입 니 다. 0 디스크 에 중요 한 데이터(호스트 정보 와 로그 파일)를 RAID 로 저장 합 니 다. 0+1 또는 RAID N 디스크 에 있 습 니 다.패 리 티 를 업데이트 하기 때문에 많은 기록 이 있 습 니 다.RAID N 이 문제 일 수도 있어 요. 데이터베이스 에 사용 할 파일 시스템 에 파 라 메 터 를 설정 할 수 있 습 니 다.쉬 운 변 화 는 noatime 옵션 으로 파일 시스템 을 연결 하 는 것 입 니 다.이것 은 inode 에 업 데 이 트 된 마지막 접근 시간 을 건 너 뛰 고 디스크 길 찾기 를 피 할 수 있 습 니 다. 데이터베이스 디 렉 터 리 이동 표 와 데이터 베 이 스 를 다른 곳 으로 이동 시 키 고 새로운 장소 로 연 결 된 기호 로 대체 할 수 있 습 니 다.예 를 들 어 데이터 베 이 스 를 더 많은 공간 이 있 는 파일 시스템 으로 옮 기 려 고 할 수도 있 습 니 다. MySQL 에서 표 가 심 볼 릭 링크 라 는 것 을 알 게 되면 심 볼 릭 링크 를 분석 하고 실제 가리 키 는 표를 사용 합 니 다.realpath()호출 을 지원 하 는 모든 시스템 에서 작업 할 수 있 습 니 다. Linux 와 Solaris 는 realpath()를 지원 합 니 다!realpath()가 지원 되 지 않 는 시스템 에 서 는 실제 경로 와 심 볼 릭 링크 를 통 해 접근 하지 않 아야 합 니 다!만약 당신 이 이렇게 한다 면,시 계 는 어떤 업데이트 후에 도 일치 하지 않 을 것 입 니 다. MySQL 결 성 은 데이터베이스 링크 를 지원 하지 않 습 니 다.데이터베이스 사이 에 심 볼 릭 링크 를 만 들 지 않 으 면 모든 것 이 정상적으로 작 동 합 니 다.MySQL 데이터 디 렉 터 리 에 데이터베이스 db1 이 있다 고 가정 하고 심 볼 릭 링크 db2 가 db1 을 가리 키 는 것 을 만 들 었 습 니 다. shell&> cd /path/to/datadir shell&> ln -s db1 db2 현재 db1 에 있 는 모든 표 tbla,db2 종 에 도 표 tbl 이 있 는 것 같 아 요.a.한 스 레 드 가 db1.tbl 을 업데이트 하면a.그리고 다른 스 레 드 업데이트 db2.tbla,문제 가 있 을 거 예요. 만약 당신 이 확실히 이렇게 필요 하 다 면,아래 의"my sys/mf"를 바 꿔 야 합 니 다.format.c"의 코드: if (!lstat(to,&stat_buff)) /* Check if it's a symbolic link */ if (S_ISLNK(stat_buff.st_mode) && realpath(to,buff)) 코드 를 이렇게 변경 합 니 다: if (realpath(to,buff))
