저도 평범한 유저인데요,

잘 아시겠지만 db데몬이 텍스트 레코드는 5개가 되건 5천만개가 되건 어차피 디스크에 저장합니다.

쿼리만 메모리에서 동작하면되겠고요, 엔진이 어떤것인지 모르지만 Select가 많으면 쿼리쪽을

Insert와 update가 많으면 엔진의 종류를 바꿔보는 것이 좋겠지요.

잘 아시겠지만, 이런 부분은 Kboard나 워드프레스의 문제가 아니라 순수하게 서버단 db 환경의 문제로 귀결됩니다.

말씀하신 보드류나 K보드, 워드프레스로 차원이 아니라 서버단 io로드와 리프레시 비율에 따라 세팅하시면 되고요,

한 일 이주 러닝시켜보시고 mysql -e "show variables like 'query_cache_%'"해서 보시고 설정하시면 되겠고요,

쿼리캐시는 리프레시 비율에 따라 용량을 적절히 설정하지 않으면, 커도 엔진에 따라 역효과가 날수도 있으니 엔진과 같이 튜닝하시면 됩니다.

그리고 "5천개 단위로 잘라서 저장" <= 이건 그렇게 하시기 원하시면 직접 별도의 id를 추가 생성하는 식으로 개조 하시면 되겠지만

요즘의 db환경에서는 굳이 그렇게 하실 필요까지는 없으실거예요.

워드프레스.org 사이트의 수억개의 게시글에 대해 우리가 불편을 느끼지는 않는.. 그런 식입니다.

좋은 결과가 있기 바랍니다.

좋은 플러그인 만들어주셔서 감사합니다.

배준석님 답변 감사합니다.

배준석님의 답변을 듣고 서버 DB의 문제인가를 확인하여 서버 쿼리 캐시 관련하여 세팅을 하였는데 문제는 해결되지 않았습니다.

show status like "qcache%";

의 명령어로 확인 결과

 +-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 2         |
| Qcache_free_memory      | 227385824 |
| Qcache_hits             | 743       |
| Qcache_inserts          | 402       |
| Qcache_lowmem_prunes    | 0         |
| Qcache_not_cached       | 92        |
| Qcache_queries_in_cache | 373       |
| Qcache_total_blocks     | 798       |

로 세팅을 하였지만, 느려지는 현상은 완화되지 않았습니다.

그리고 kboard에서 쓰는 쿼리를 직접 콘솔로 접속하여 실행에 보았습니다.

결과는 1.20초대로 여러번 쿼리한 결과 거의 동일하게 나왔습니다.

작성한 쿼리는 아래와 같습니다.

SELECT * FROM `kboard_board_content` WHERE `board_id`='6' AND `notice` LIKE '' ORDER BY `date` DESC LIMIT 30000,10;

이 쿼리에서 조금 씩 변경하여서 쿼리를 실행해 보았습니다.

무엇이 문제일까요? 아직 서버에서 세팅할게 더 남아 있을까요?