저는 웹 사이트 프로젝트의 약 10 %를 차지하고 있으며 데이터베이스에 어떤 종류의 부하가 걸리고 있는지 파악하려고합니다. 사용자가 로그인하면 매분마다 트리거되는 많은 기능이 있으며 누군가가 페이지를 방문 할 때마다 지역 코드 목록, 주 및 국가와 같은 여러 요소가 등록 페이지를 작성하기 위해 끌어 당깁니다. 나는 그 중 일부를 PHP로 옮겨서 데이터베이스가 관련되지 않을 것이라고 확신한다.백엔드에서 mysql을 사용하는 웹 사이트의 평균 또는 높은로드로 간주되는 사항은 무엇입니까?
6 일, 14 시간 57 분 58 초로 평균 12.69 k/초 및 211.43 초의 쿼리를 120,998,563 회 표시합니다. 79 개의 최대 동시 연결 수를 나열하고 있습니다.이 두 개의 마지막 연결은 의미가 없습니다. 시간당 평균 133 MiB를 받았으며 분당 평균 1,997 MiB를 받았습니다.
쿼리 수가 많을수록 중요한 점은 무엇인지, 그리고 테이블에 수백만 개의 행이 있고 올바른 인덱스를 사용하지 않으면 서버가 떨어지는 것입니다. 쿼리가 적절한 인덱스가있는 매우 최적화되어 있고 많은 데이터가 없으면 서버가 살아납니다.
당신은
다음 인덱스 ;-), 당신은 아마 mecanism 캐싱 때문에 가지 추가 할 것이다 사용/적어도 그 최적화되어 있는지, 가장 사용되는 쿼리에 EXPLAIN을 사용할 수 있습니다 예 : APC 또는 memcached; 적어도 ... 할 수 있으면 ...
예를 들어 목록 상태와 국가는 변경되지 않을 가능성이 있습니다. 데이터베이스를 수천 번이나 캐시하지 않고 하루에 한 번 또는 한 시간에 한 번만 캐시 할 수 있습니다.
하나의 소스를 찾았을 수도 있습니다. 데이터베이스에 16x16 아바타 축소판 그림과 192x192의 숫자를 추가했습니다. 나는 그 중 하나가 보일 때마다 데이터베이스 질의가 만들어지고 때로는 사용자가 화면에 20 개를 가질 것이라고 생각하기 위해 멈추지 않았다. 메신저 패널에서는 매 30 초마다 새로 고칩니다. 나는 모든 이미지를 꺼내고 디렉토리 구조에서 정상적으로 저장/참조하고 있습니다. –
가능하다면 실제로 문제가 될 수 있습니다 .-); 하지만 내가 말했듯이 설명하고 모든 것이 여전히 사실이다 ;-)는 어느 날 또는 다른 날에 유용 할 것이다 ;-) –
가장 좋은 점은 페이지 당 쿼리 수를 확인한 다음 해당 쿼리 유형을 조사하는 것입니다. 예를 들어 간단한 SELECT 문은 매우 빠르지 만, 3 개의 테이블을 결합하면 매우 느립니다. 또한 데이터베이스 테이블의 인덱스와 한계에 따라 달라집니다.
기본적으로, 우리는 실제로 당신에게 말할 충분한 정보가 없습니다. 당신이 준 것조차도, 한 번에 많은 수의 사용자가 몰라도 꽤 쓸모가 없습니다.
조인의 인덱스가 적절하면 조인 속도가 느리지 않습니다. –
데이터베이스에 대해 많이 알지는 못하지만 알아두면 알 수 있듯이 색인은 비싼 임시 테이블이 필요하지 않음을 의미하지는 않습니다. ++ –
느린 쿼리 로그 (http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html)를 활성화하고 모니터링하기를 원할 수 있습니다. 쿼리의 수가 인덱스를 치는 동안 또는 쿼리 캐시가 더 나은 경우에도 항상로드가 높은 것은 아닙니다. 약간 잘못 설계된 쿼리는 서버를 죽일 수 있습니다. 느린 쿼리 로그는 그러한 쿼리를 지적하므로 시간을 최적화하여 최적화 할 수 있습니다.
다른 사람들이 말했듯이 쿼리의 수는 별 문제가 아니며 더 많은 쿼리 유형과 데이터베이스의 인덱싱 정도입니다. 또한 다른 사람이 APC 또는 memcache와 같은 캐싱 메커니즘을 살펴 보았지만 PHP 클래스 캐싱 시스템도 권해드립니다. zend 프레임 워크에는 하나가 있고 저는 개인적으로 PEAR 라이브러리에서 Cache_Lite을 사용합니다. 사물의 PHP 수준에서 절대적으로 최신 업데이트 된 정보 일 필요가없는 db 쿼리를 캐시 할 수 있습니다. 따라서 페이지가 실행되는 경우 10 개의 검색어를 말하면되지만 실제로는 2 ~ 3 개만 신선한 정보가되어야 다른 검색어를 5 ~ 10 분 동안 캐시 할 수 있습니다. 1 분의 캐시도 대량의 사이트에서 많은 거래를 절약 할 수 있습니다.
좀 더 팁 :
A - 당신이 NXN 런타임 쿼리를 실행하지 않는 확인 (또는 적어도만큼 당신이 할 수있는 한 그것을 피하려고).어떻게 내가 그 뜻을 가지 마세요된다
- 쿼리 -while (쿼리) - 쿼리 1 - 동안 (쿼리 1) - 엔드 쿼리
확실히이 돈 쿼리 1 -end 동안 동안 ' 3 단계 (n^3)로 ...
B - 속도에 관한 또 다른 사항 :하지 말아야 할 때 - 가지 말아주세요. 선택 *에서. 이름과 성만 필요한 경우 다음을 선택하십시오. 데이터가 더 빨리 되돌아옵니다. 당신은 그것을 빨리 통과 할 수있을 것입니다.
나는 한 번 저자가 백만 행 테이블을 통해 비교를 한 기사를 읽었으며 Select *와 Select col1, col2, col3. . . 내 Google 닌자 스킬이 오늘 빠져 있어야합니다. 기사를 찾을 수없는 것 같습니다. 내가 정확하게 기억한다면, 표는 적절한 색인과 키를 가져야한다는 것입니다. 어쨌든 좋은 데이터베이스 디자인의 핵심은 아닌가? – andrewWinn
hmmm ... 흥미로운 것으로 들리지만 ... 30 개 중 하나의 열만 검색하면 DB에서 한 열 데이터가 더 빨리 전송된다는 것이 확실합니다. 적은 양의 데이터가 더 빠릅니까? –
@officeJet - 그렇기 때문에 Google Ninja 기술 부족으로 화가났습니다. . . 나는이 기사를 읽고 즉시 놀랐던 모든 DBA와 공유했다. . 나는 당신이 묘사 한 상황에서, 당신이 옳다고 생각하지만, 그것은 질문을합니다. 왜 당신은 단지 30 개 중 한 컬럼을 끌어 당기고 있습니까? 리팩토링 할 시간 은요? ;) – andrewWinn
또 다른 요소는 호스팅 환경입니다. 많은 공유 호스트에서 허용되는 동시 데이터베이스 연결 수에는 제한이 있으며,이 제한은 놀랍게도 낮을 수 있습니다. 통계적으로 방문자가 하루 종일 균등하게 분산되어 있다고 가정하면 일반적으로 괜찮습니다. 그러나 특정 시간에 콘텐츠가 나올 것으로 예상되는 대규모 시청자가있는 경우 모두가 요청하는 경우 사용 가능한 연결을 최대한 활용할 수 있습니다 좁은 시간 프레임에서 스크립트 (및 데이터베이스 연결 열기).
데이터베이스가 최적화되어 있고 인덱스가 양호한 경우 PHP가 아닌 db를 작업하게 만드는 것이 거의 항상 빠릅니다. –