100만개 이상의 회원 데이터가 존재할때 그누보드 관리자.....질문입니다. 정보
100만개 이상의 회원 데이터가 존재할때 그누보드 관리자.....질문입니다.
본문
100만개 이상의 회원 데이터가 존재할때 그누보드 관리자.....질문입니다.
일단 회원가입부분의 처리속도는 인덱스키값을 따로 두어 속도차를 해결하였습니다만..
그누보드 관리자에서 한꺼번에 데이터를 불러들이는거 같더군요..
역시나 관리자에서는 8초에서 16초 정도로 오래 걸립니다 ㅜㅜ
특히나 회원관리 부분과 처음 admin 모드로 접속시도시 느려지구요..
해결방법이 없을까요?
댓글 전체
일반사용자들은 거의 느낄수 없는 상태이므로 체크가 힘들듯 하군요.
회원이 100만개 이상 있는곳에서 테스트를 해봐야 할듯 ..
회원이 100만개 이상 있는곳에서 테스트를 해봐야 할듯 ..
member_list 를 예로 들자면, 상단부분에 쿼리문이 있습니다.
이걸 아래질문에서 추가한 인덱스에 맞도록 순서와 where/and/or 을 맞게 변경해 주십시오.
또는 인덱스가 없을 경우, 인덱스를 추가해 주십시오.
(가능한 회원리스트에서 사용하는 검색/정렬 필드등은 인덱스를 잡아주십시오.)
또한 루프문 내에 있는 아래 카운트 구하는 쿼리등을 num_rows() 로 모두 변경해 주십시오.
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = sql_fetch($sql2);
를
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = mysql_num_rows(sql_query($sql2));
그리고 아래에서 $row2[cnt] 라는 부분을 $row2 로 모두 수정해 주십시오.
* 자료가 많지않을 경우는 큰 속도차이를 느낄 수 없으나, 백만건 정도라면 꽤 차이가 날 것입니다.
(mysql 레퍼런스에서도 단순 카운트의 경우는 num_rows() 가 훨씬 빠르다고 나와 있으며, num_rows() 로 카운트를 할 경우는 특정 필드를 셀렉트하지말고 * 로 카운트하라고 권장하고 있습니다.)
* 다른 부분들도 둘러보면서 상황에 맞게 수정을 가해야될 부분들이 좀 있는걸로 보입니다..
인덱스파일이나 나머지 부분은 위 사항을 참고하셔서 직접 수정하십시오.
* 한 가지 더 참고하자면, 회원자료가 100만건 정도라면 보드테이블도 상당할 걸로 생각됩니다.
그렇다면 이렇게 주먹구구식으로 해서 될 것이 아니라, 회원/보드관련 부분에 대한 튜닝 기획/설계를 해서 모두 튜닝을 해주고 사용하는 방법을 권해 드립니다.
이걸 아래질문에서 추가한 인덱스에 맞도록 순서와 where/and/or 을 맞게 변경해 주십시오.
또는 인덱스가 없을 경우, 인덱스를 추가해 주십시오.
(가능한 회원리스트에서 사용하는 검색/정렬 필드등은 인덱스를 잡아주십시오.)
또한 루프문 내에 있는 아래 카운트 구하는 쿼리등을 num_rows() 로 모두 변경해 주십시오.
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = sql_fetch($sql2);
를
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = mysql_num_rows(sql_query($sql2));
그리고 아래에서 $row2[cnt] 라는 부분을 $row2 로 모두 수정해 주십시오.
* 자료가 많지않을 경우는 큰 속도차이를 느낄 수 없으나, 백만건 정도라면 꽤 차이가 날 것입니다.
(mysql 레퍼런스에서도 단순 카운트의 경우는 num_rows() 가 훨씬 빠르다고 나와 있으며, num_rows() 로 카운트를 할 경우는 특정 필드를 셀렉트하지말고 * 로 카운트하라고 권장하고 있습니다.)
* 다른 부분들도 둘러보면서 상황에 맞게 수정을 가해야될 부분들이 좀 있는걸로 보입니다..
인덱스파일이나 나머지 부분은 위 사항을 참고하셔서 직접 수정하십시오.
* 한 가지 더 참고하자면, 회원자료가 100만건 정도라면 보드테이블도 상당할 걸로 생각됩니다.
그렇다면 이렇게 주먹구구식으로 해서 될 것이 아니라, 회원/보드관련 부분에 대한 튜닝 기획/설계를 해서 모두 튜닝을 해주고 사용하는 방법을 권해 드립니다.
으... 애매합니다 ㅡㅜ 일단 관리자모드에서 읽어들이는 부분인 mb_level mb_mailer mb_open mb_mail.... 등등등
을 인덱스 키값으로 정해 두었습니다..
위의 소스대로 카운트되는 부분들을 수정하였습니다.. 역시나 속도차는 해결이 나지 않고 있습니다..
보드부분은 제쳐 두더라도 당장은 회원데이터가 문젠데요 ㅡㅜ 손이 많이 갈꺼 같아 어디서 부터 손을 대햐할지 모르겠습니다.
여하튼 친절히 도움을 주셔서 감사합니다.
을 인덱스 키값으로 정해 두었습니다..
위의 소스대로 카운트되는 부분들을 수정하였습니다.. 역시나 속도차는 해결이 나지 않고 있습니다..
보드부분은 제쳐 두더라도 당장은 회원데이터가 문젠데요 ㅡㅜ 손이 많이 갈꺼 같아 어디서 부터 손을 대햐할지 모르겠습니다.
여하튼 친절히 도움을 주셔서 감사합니다.
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
보다
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
가 더 느리지 않나요?
위에것은 한 줄 가져 와서 php에서 그 줄에 있는 값을 주고
아래것을 백만줄을 가져 와서 php에서 백만줄을 세거나 그 안에 있는 줄 수를 넘겨주겠죠.
보다
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
가 더 느리지 않나요?
위에것은 한 줄 가져 와서 php에서 그 줄에 있는 값을 주고
아래것을 백만줄을 가져 와서 php에서 백만줄을 세거나 그 안에 있는 줄 수를 넘겨주겠죠.
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
위의 쿼리대로 적용하면 페이지 로딩 타임이 약 15.5초 정도 걸립니다.
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
또 * from 으로 전부 가져오면 16초정도 쿼리타임이 나옵니다...
이거 무지 애매하네요 ㅜㅜ 대형 웹사이트를 처음 접하다보니.. 테이블 전체를 다시 디자인해야 할 듯 싶습니다.
ㅜㅡ
위의 쿼리대로 적용하면 페이지 로딩 타임이 약 15.5초 정도 걸립니다.
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
또 * from 으로 전부 가져오면 16초정도 쿼리타임이 나옵니다...
이거 무지 애매하네요 ㅜㅜ 대형 웹사이트를 처음 접하다보니.. 테이블 전체를 다시 디자인해야 할 듯 싶습니다.
ㅜㅡ
디자인 다시하는 것보다 현 상태에서
인덱스 구성을 다시 검토해 보세요.
그게 그말인가요? ^^
인덱스 구성을 다시 검토해 보세요.
그게 그말인가요? ^^
> $sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
> 위의 쿼리대로 적용하면 페이지 로딩 타임이 약 15.5초 정도 걸립니다.
$g4[group_member_table] 테이블에 mb_id가 인덱스 설정되어있는데도
15.5초가 걸린다면 서버의 성능이나 DB의 성능을 의심해봐야 하지 않을까 싶군요.
100만건이라해도 인덱스 설정된 테이블의 조회가 15초 이상걸린다는 것은 잘 이해가 되지 않는군요.
> 위의 쿼리대로 적용하면 페이지 로딩 타임이 약 15.5초 정도 걸립니다.
$g4[group_member_table] 테이블에 mb_id가 인덱스 설정되어있는데도
15.5초가 걸린다면 서버의 성능이나 DB의 성능을 의심해봐야 하지 않을까 싶군요.
100만건이라해도 인덱스 설정된 테이블의 조회가 15초 이상걸린다는 것은 잘 이해가 되지 않는군요.
거의 같은 시간이면 인덱스 안 쓴다고 봐야겠습니다. ^^
show index from $g4[group_member_table]
한번 해서 보여 주세요.
show index from $g4[group_member_table]
한번 해서 보여 주세요.
소스를 아무리 봐도 member_list.php 는 adm 모드에서 관련되어지는 부분이 맞는거 같습니다...
서버의 사양은 xeon 2.0 dual memory 2gb 입니다. 서버의 사양또한 딸린다고 할수는 없습니다.
서버의 사양은 xeon 2.0 dual memory 2gb 입니다. 서버의 사양또한 딸린다고 할수는 없습니다.
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
g4_group_member 0 PRIMARY 1 gm_id A 0 NULL NULL BTREE
g4_group_member 1 gr_id 1 gr_id A NULL NULL NULL BTREE
g4_group_member 1 mb_id 1 mb_id A NULL NULL NULL BTREE
입니다. 역시 키값이 등록이 되어있습니다. 해당 결과는 그누보드를 디폴트로 설치했었을때와 동일합니다.
g4_group_member 0 PRIMARY 1 gm_id A 0 NULL NULL BTREE
g4_group_member 1 gr_id 1 gr_id A NULL NULL NULL BTREE
g4_group_member 1 mb_id 1 mb_id A NULL NULL NULL BTREE
입니다. 역시 키값이 등록이 되어있습니다. 해당 결과는 그누보드를 디폴트로 설치했었을때와 동일합니다.
카운트에 대해 잘못 알고 계신것 같아서 한 마디 더 적겠습니다.
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = sql_fetch($sql2);
를
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = mysql_num_rows(sql_query($sql2));
위의 예에서 아래쪽에 있는 카운팅 함수가 fetch 가 아닌 num_rows 인걸 볼 수 있습니다.
일반적으로 select count(*) 나 select count(mb_id) 등을 해서 fetch_array 로 가져오면 빠르지 않냐고 생각합니다.
그러나 mysql 레퍼런스에 있듯이 단순한 카운트(필드값을 체크하는게 아니라 해당 rows 에서 0 번을 카운트만 합니다.) 만 할 경우는 select * 와 num_rows() 가 훨씬 빠르다는 것을 강조하고 있습니다.
* 그리고 질문하신 분의 경우,
아래 질문에도 제가 말씀을 드렸고, 그대로 해서 상당한? 단축을 하셨다고 했듯이, 질문하신 의도나 지금 일단 급하니 보이는것만 어떻게든 해보자...라는 생각으로 주먹구구식으로 하려고 하는건 절대 좋은 생각이 아닙니다.
그리고 모 사이트에서도 답변을 달면서 예를 들었는데, 제가 로컬서버에 특정 쿼리 및 튜닝을 테스트해서 최적의 효율성을 내기위해서 작업용 로컬서버에 각각 몇 개의 테이블을 만들어 놓고, 자료를 10만건,50만건,100만건,150만건,200만건 을 각각 넣고 최적의 쿼리가 필요할 때 사용하고 있습니다.
이런 작업환경을 만들어놓고, 테스트를 하면서 튜닝을 하시든지, 아니면 튜닝에 대한 기획/설계를 해서 단계적으로 튜닝을 하십시오.
그렇지 않으면 계속 문제가 지속될 것입니다.
또한 위 예제와 저 위의 예제에서는 제가 간략히 예를 든 것입니다. 저런형태를 참고하여 인덱스 및 그룹인덱스(개별도 물론)등을 잘 설계하여 잡으라는 얘기였고, 해당 파일 및 파일에서 호출되는 펑션(모듈등)등을 잘 검토하여 새로 로직을 짜야하는 부분이 있다면 당연히 새로 짜야 합니다.
* 100만건 정도에서 최적쿼리 및 최적의 페이지 로딩을 찾는게 그렇게 쉽다면 100만건(또는 비슷하거나 그 이상)의 rows 를 가진 db를 튜닝하는 전문가가 필요하지 않겠지요.
너무 쉽게 생각을 하시는듯 합니다..
$sql2 = " select count(*) as cnt from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = sql_fetch($sql2);
를
$sql2 = " select * from $g4[group_member_table] where mb_id = '$row[mb_id]' ";
$row2 = mysql_num_rows(sql_query($sql2));
위의 예에서 아래쪽에 있는 카운팅 함수가 fetch 가 아닌 num_rows 인걸 볼 수 있습니다.
일반적으로 select count(*) 나 select count(mb_id) 등을 해서 fetch_array 로 가져오면 빠르지 않냐고 생각합니다.
그러나 mysql 레퍼런스에 있듯이 단순한 카운트(필드값을 체크하는게 아니라 해당 rows 에서 0 번을 카운트만 합니다.) 만 할 경우는 select * 와 num_rows() 가 훨씬 빠르다는 것을 강조하고 있습니다.
* 그리고 질문하신 분의 경우,
아래 질문에도 제가 말씀을 드렸고, 그대로 해서 상당한? 단축을 하셨다고 했듯이, 질문하신 의도나 지금 일단 급하니 보이는것만 어떻게든 해보자...라는 생각으로 주먹구구식으로 하려고 하는건 절대 좋은 생각이 아닙니다.
그리고 모 사이트에서도 답변을 달면서 예를 들었는데, 제가 로컬서버에 특정 쿼리 및 튜닝을 테스트해서 최적의 효율성을 내기위해서 작업용 로컬서버에 각각 몇 개의 테이블을 만들어 놓고, 자료를 10만건,50만건,100만건,150만건,200만건 을 각각 넣고 최적의 쿼리가 필요할 때 사용하고 있습니다.
이런 작업환경을 만들어놓고, 테스트를 하면서 튜닝을 하시든지, 아니면 튜닝에 대한 기획/설계를 해서 단계적으로 튜닝을 하십시오.
그렇지 않으면 계속 문제가 지속될 것입니다.
또한 위 예제와 저 위의 예제에서는 제가 간략히 예를 든 것입니다. 저런형태를 참고하여 인덱스 및 그룹인덱스(개별도 물론)등을 잘 설계하여 잡으라는 얘기였고, 해당 파일 및 파일에서 호출되는 펑션(모듈등)등을 잘 검토하여 새로 로직을 짜야하는 부분이 있다면 당연히 새로 짜야 합니다.
* 100만건 정도에서 최적쿼리 및 최적의 페이지 로딩을 찾는게 그렇게 쉽다면 100만건(또는 비슷하거나 그 이상)의 rows 를 가진 db를 튜닝하는 전문가가 필요하지 않겠지요.
너무 쉽게 생각을 하시는듯 합니다..
위의 예에서 아래쪽에 있는 카운팅 함수가 fetch 가 아닌 num_rows 인걸 볼 수 있습니다.
일반적으로 select count(*) 나 select count(mb_id) 등을 해서 fetch_array 로 가져오면 빠르지 않냐고 생각합니다.
그러나 mysql 레퍼런스에 있듯이 단순한 카운트(필드값을 체크하는게 아니라 해당 rows 에서 0 번을 카운트만 합니다.) 만 할 경우는 select * 와 num_rows() 가 훨씬 빠르다는 것을 강조하고 있습니다.
이 말을 분석해 보면
mysq_fetch_row() 또는 mysql_fetch_array()함수에서 실제 데이터를 가져온다는 말이되겠네요. 그런가요?
mysql 레퍼런스 링크를 보여 주실 수 있나요? 정독을 해 보려고요.
일반적으로 select count(*) 나 select count(mb_id) 등을 해서 fetch_array 로 가져오면 빠르지 않냐고 생각합니다.
그러나 mysql 레퍼런스에 있듯이 단순한 카운트(필드값을 체크하는게 아니라 해당 rows 에서 0 번을 카운트만 합니다.) 만 할 경우는 select * 와 num_rows() 가 훨씬 빠르다는 것을 강조하고 있습니다.
이 말을 분석해 보면
mysq_fetch_row() 또는 mysql_fetch_array()함수에서 실제 데이터를 가져온다는 말이되겠네요. 그런가요?
mysql 레퍼런스 링크를 보여 주실 수 있나요? 정독을 해 보려고요.
fetch 는 배열값을 그대로 반환합니다.
$row = mysql_fetch_array($result);
print_r($row); // 찍어보시면 실제 컬럼값을 모두 갖고 있는것을 알 수 있습니다.
*또한 fetch 함수는 풀스캔을 일으키는 요지가 많습니다. (정확한 인덱스의 경우는 아닙니다)
그래서 단순한 카운트일 경우는 num_rows 가 빠르다고 하는게 아닌가(mysql 측에서) 하는 생각을 합니다.
$row = mysql_fetch_array($result);
print_r($row); // 찍어보시면 실제 컬럼값을 모두 갖고 있는것을 알 수 있습니다.
*또한 fetch 함수는 풀스캔을 일으키는 요지가 많습니다. (정확한 인덱스의 경우는 아닙니다)
그래서 단순한 카운트일 경우는 num_rows 가 빠르다고 하는게 아닌가(mysql 측에서) 하는 생각을 합니다.
select count(*) 나
select *나
이후에 mysql_num_row()가 올지 mysql_fetch_*가 올지는 모르는 상태에서
위 글들을 종합해 보면
mysql_fetch_*까지는 데이터를 가져 오지 않는 것이 맞는 듯 합니다.
php모듈과 mysql 서버가 독립된 process인 걸 감안하면 몇 만건의 row 데이터가 전송 되어야 합니다.
select *나
이후에 mysql_num_row()가 올지 mysql_fetch_*가 올지는 모르는 상태에서
위 글들을 종합해 보면
mysql_fetch_*까지는 데이터를 가져 오지 않는 것이 맞는 듯 합니다.
php모듈과 mysql 서버가 독립된 process인 걸 감안하면 몇 만건의 row 데이터가 전송 되어야 합니다.
dev.mysql.com 에서 각각의 펑션을 모두 보시면 되겟습니다만..
http://dev.mysql.com/doc/refman/4.1/en/mysql-num-rows.html
C API를 말씀하시는건가요?
PHP 함수 설명이 de.mysql.com에는 없는 거 같은데......
아래하고 비교해서 말씀해 주시면 좋겠습니다.
http://dev.mysql.com/doc/refman/4.1/en/group-by-functions.html
COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.
COUNT(*) is optimized to return very quickly if the SELECT retrieves from one table, no other columns are retrieved, and there is no WHERE clause. For example:
mysql> SELECT COUNT(*) FROM student;
This optimization applies only to MyISAM and ISAM tables only, because an exact row count is stored for these storage engines and can be accessed very quickly. For transactional storage engines such as InnoDB and BDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.
C API를 말씀하시는건가요?
PHP 함수 설명이 de.mysql.com에는 없는 거 같은데......
아래하고 비교해서 말씀해 주시면 좋겠습니다.
http://dev.mysql.com/doc/refman/4.1/en/group-by-functions.html
COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values.
COUNT(*) is optimized to return very quickly if the SELECT retrieves from one table, no other columns are retrieved, and there is no WHERE clause. For example:
mysql> SELECT COUNT(*) FROM student;
This optimization applies only to MyISAM and ISAM tables only, because an exact row count is stored for these storage engines and can be accessed very quickly. For transactional storage engines such as InnoDB and BDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.
* 수정합니다.
정확한 테스트를 위해서 자료를 조금씩 넣으면서 해보니 일정 레코드수 이하는 select count(*) 로 fetch 가 빠르고,
대략 10~30만건 정도는 거의 같고, 그 이상부터는 num_rows 가 빠르더군요..
자료가 많을수록 빠르다는 뜻인데..
일단 이번은 다른 작업중에 단순한 테스트였습니다.
제가 알고 있는것이 잘못된것일수도 있으므로, 다른분들에게 혼란을 드리지 않기위해서 잠깐 확인을 해봤습니다.
조만간 시간을 내서 10만건씩 끊어서 정확한 테스트를 해보고 다시 올리든지..(문제는 삼는분 없으면 그냥 꿀꺽~)
이상입니다.
정확한 테스트를 위해서 자료를 조금씩 넣으면서 해보니 일정 레코드수 이하는 select count(*) 로 fetch 가 빠르고,
대략 10~30만건 정도는 거의 같고, 그 이상부터는 num_rows 가 빠르더군요..
자료가 많을수록 빠르다는 뜻인데..
일단 이번은 다른 작업중에 단순한 테스트였습니다.
제가 알고 있는것이 잘못된것일수도 있으므로, 다른분들에게 혼란을 드리지 않기위해서 잠깐 확인을 해봤습니다.
조만간 시간을 내서 10만건씩 끊어서 정확한 테스트를 해보고 다시 올리든지..(문제는 삼는분 없으면 그냥 꿀꺽~)
이상입니다.
이 문제는 그만 얘기했으면 합니다.
개개인마다 즐겨쓰는 함수가 다르고, 코딩하는 습관이 다르고, 로직 기획/설계가 다 다르니..
사이트 부하를 일으키지 않는다면 자신의 방법대로 하는것이 정석이라고 생각합니다.
(다만 원래 질문하신분처럼 페이지 로딩이 8~16초 정도가 걸리면 심각한 문제라고 봅니다.)
* 그리고 위에서 제가 예를 든 컬럼값들을 반환한다는 함수는 당연히 fetch_array 입니다. 길게쓰기 귀찮아서 일반적으로 fetch_array 를 사용하므로 fetch 로만 표기하였습니다.
정확히 바로잡도록 하겠습니다. mysql_fetch_array() 입니다.
// rolo
* 위 레퍼런스 링크는 mysql 입니다. php 함수가 있는게 이상합니다만..
* 공부하시고 싶은 분들은 관련 자료나 서적 혹은 웹사이트 dev.mysql.com, php.net 을 참고하셔서 공부하시면 되겠습니다.
개개인마다 즐겨쓰는 함수가 다르고, 코딩하는 습관이 다르고, 로직 기획/설계가 다 다르니..
사이트 부하를 일으키지 않는다면 자신의 방법대로 하는것이 정석이라고 생각합니다.
(다만 원래 질문하신분처럼 페이지 로딩이 8~16초 정도가 걸리면 심각한 문제라고 봅니다.)
* 그리고 위에서 제가 예를 든 컬럼값들을 반환한다는 함수는 당연히 fetch_array 입니다. 길게쓰기 귀찮아서 일반적으로 fetch_array 를 사용하므로 fetch 로만 표기하였습니다.
정확히 바로잡도록 하겠습니다. mysql_fetch_array() 입니다.
// rolo
* 위 레퍼런스 링크는 mysql 입니다. php 함수가 있는게 이상합니다만..
* 공부하시고 싶은 분들은 관련 자료나 서적 혹은 웹사이트 dev.mysql.com, php.net 을 참고하셔서 공부하시면 되겠습니다.
adm/index.php에 이런 것이 있는데
if ($is_admin != 'super')
$sql_search .= " and mb_level <= '$member[mb_level]' ";
if (!isset($sst)) {
$sst = "mb_datetime";
$sod = "desc";
}
...
..
.
==============
g4_member에 추가로 인덱스를
alter table g4_member add index level( mb_level, mb_datetime)
정도를 해 보세요.
그런데 문제는
이 query 이후로 계속 회원 정보 필드 값으로 계속 필터링하는 query가 몇 개 더 있네요.
mb_leave_date, mb_intercept_date,
둘 다 따로, 따로 index를 만들어 주시던가
테이블을 별도 하나 만들어서 이 정보를 저장하던가 해야겠습니다.
if ($is_admin != 'super')
$sql_search .= " and mb_level <= '$member[mb_level]' ";
if (!isset($sst)) {
$sst = "mb_datetime";
$sod = "desc";
}
...
..
.
==============
g4_member에 추가로 인덱스를
alter table g4_member add index level( mb_level, mb_datetime)
정도를 해 보세요.
그런데 문제는
이 query 이후로 계속 회원 정보 필드 값으로 계속 필터링하는 query가 몇 개 더 있네요.
mb_leave_date, mb_intercept_date,
둘 다 따로, 따로 index를 만들어 주시던가
테이블을 별도 하나 만들어서 이 정보를 저장하던가 해야겠습니다.
