select * 대신 select 필요한 필드 ...로 변경하세요. 속도가 팍~ 달라집니다.

ㅎㅎ...

레코드 수에 따라서 다룰 수 있겠지만 답은 나가 더 빨라요.

ioncube의 loader의 효율을 보았는데, 1회에는 월등하지만 횟수가 급격히 늘어나게 되니까 원점이 되어버리더군요. 제가 튜닝을 하면서 가장 크게 생각하는 것이 connection 입니다. connection의 문제는 MySQL에서도 인식하고 있기 때문에 php와 연결하는 lib을 새로 개발해서 5.1부터 적용하려고 하고 있죠.

사이트가 느리고 시스템의 용량이 충분하면 connection이 문제가 안되지만, 트래픽이 많다면 한번의 연결에 필요한 모든 것을 해결하는게 더 효율적이죠.

제가 튜닝을 할 때 가장 중점을 두는 것은 SQL connection 횟수 자체를 줄이는 것 입니다. 실제로 횟수가 줄어들면 효과가 팍팍~ 나오더라구요. 다음으로 필요한 것만 select를 하고 group by가 있는 경우 인덱스를 다시 잡아주고, 불필요한 join을 없애는 것 입니다.

제가 트래픽이 아주 과다한 사이트에서 두가지를 실제로 다 해본 경험으로 답이 나. 입니다.

사실 나.가 되는 가장 큰 이유중 하나가 connection 할 때 발생하는 network traffic 입니다. 생각없이 웹서버-db서버를 분리해서 운영하다가 지금은 2nd LAN card로 local lan을 하나 더 만들어서 db connection만 따로 분리한 것이, 웹 traffic이 20G일 때, 웹-DB traffic이 40G이상이었기 때문이죠. 이정도로 traffic이 걸리면 network card부터 data bus까지 모두 혼동에 들어가서 효율이 떨어지게 되는 겁니다.

MySQL의 횟수를 줄여서 network traffic을 줄이는거. 그게 제가 나.를 선택하는 이유 입니다. 실제로 제가 경험하고 튜닝의 지침으로 삼고 있는 원칙이구요.

웹서버가 하루 traffic 80G까지 올라가서 쫓겨날 뻔 했을 때부터 튜닝을 시작했고, 지금은 서버 변경없이 page view를 두배 올릴 수 있었던 것은, sql query 갯수 자체를 줄이는 겁니다 (join으로 변경하던가 해서)

오 좋은 말씀 감사 드립니다. 많이 배웠네요.^^

이건 볼것도 없이 "가" 가 빠르죠.
비교대상이 아님.

join 은 어떤 경우에서도 느릴수 밖에 없습니다.
row 가 증가될수록 훨씬 큰 비용이 발생합니다.

그러나 "가"와 같은 방식으로만 쿼리를 한다면 rdbms가 아니죠^^

원론적인 얘기를 하면 길어질거 같구요. indexing 에 따라서 가변적이긴 하지만, join을 하는 경우가 훨씬 비용이 많이 발생합니다.(connection 비용은 제외)

mysql은 그나마 connection 비용이 크지 않아서 괜찮을것 같습니다.

10건짜리를 속도 생각해서 쿼리 짤 이유가 없죠.
속도가 문제되지 않는 곳이면, 자기가 편한대로 코딩하면 됩니다.

가가 빠르겟죠..

select * 를 쓰지 않고 필요 컬럼이 어떤것이냐에 따라 너무 다양하게 다른 답이 나오는건 아닌가요?

근데 '나'에서 두 테이블에 bo_table 컬럼이 있다면 인덱스가 안걸린 속성인데,
풀스캔을 하게될 때 엄청 느려질 소지가 있군요..
저는 '나'가 더 빠를 수도 있다고 보는데,
조인걸때 인덱스가 안걸린 속성으로 조인거는 거 맞죠?
그렇다면 '가'가 낫겟구요..

조인도 효과적으로 쓰이면 두 테이블 다 풀스캔하는것보다 빠를 수 있을거라 생각됩니다.

나:

가 더 빠를듯 합니다.
대신 인덱스가 제대로 걸린 상태에서요..

아무래도...
mysql에 질의 한번으로 가능한 것을.. 두번 하는 것은 좀 비효율적이라는 생각이 드는데요..

말씀하신 connection cost가 join cost보다 높을것 같다는 생각에서입니다.

실제로 임의의 레코드를 10만개 정도 넣고 테스트 해보면 답이 나오겠네요..

자세한건 mysql 의 explain 을 보세요.
굳이 성능때문에 머리 썩인적이 없어서 그냥 대충 쿼리 만듭니다.

조건절이 두개일경우는 결합 인덱스를 만들어야 하고, 인덱스를 타는 순서에 따라 결합인덱스 순서를 정해야 하고, 기본적인 지식만 가지고 쿼리를 만듭니다.
정말 속도가 중요하면 인덱싱 처리도 해야 하고, explain도 떠보고 해야 합니다.

명랑폐인 님께서 말씀하신것 처럼 결합 인덱스의 차이인듯 합니다.

결합 인덱싱의 순서도 중요하다고 들었거든요..

10만개 record 테스트는 답이 아닙니다. 10만개 record를 아주 빈번하게 query를 돌려야 합니다. 실제 웹 서버에서처럼. 그래야 정확한 테스트가 되는 것이죠. ddos 걸리는 것처럼 20-30개 정도 pc에서 집중적으로 10만개 record에 대해서 query를 날려보세요. 그게 저는 정답이라 봅니다.

지금 2대의 웹서버로 하루 페이지뷰 170만(외부 traffic 70G)을 하고 있는데, 튜닝을 통해서 200만(외부 traffic 100G - 웹/DB간의 traffic은 제외)까지 소화를 하고 (그래도 피크타임에는 response가 엉망이죠) 내년에는 서버 1대를 제온으로 바꿔서 하루 400만 페이지뷰를 소화하는 것 입니다.

제 논리는 이론적이지는 않습니다. 제가 oracle 튜닝을 강의할 때는 나름 이론적이었지만, 그게 mysql에서는 전혀 통하지 않더라구요. 그래서 무대뽀식 경험으로만 튜닝을 합니다. 코드를 수정하고 다시 원복하고 수십번 하면서 실전 테스트한 결론만 머리에 두고 참조하고 있죠.

내년에는 5.1 버젼으로 업글하고 테이블 파티셔닝을 해서 그 결과도 알려드리죠.

그렇군요...
10만개를 얼마나 빈번히 쿼리를 날리는가 겠네요^^

예. 10만개 record가 쌓인 게시판이라면 그 게시판의 동시접속 사용자수는
최소한 50-100 입니다. 그런 상황에서 join cost가 클까요? connection cost가 클까요? sql db의 cache는 얼마나 재활용 될까요? ... 그 속에 답이 있습니다.

헉 좋은 말씀 감사 드립니다.^^
항상 말씀속에 핵심이 있네요

과연 어떤 비용이 많이 들지 궁금하네요..
결과는 직접 해보는수 밖에 없겠죠^^