안녕하세요.

그 정도의 사용량으로 말씀하신 버그가 발생한다면,

MySQL을 사용하는 회사나 사람은 없을 겁니다. ^^;

그리고, 사용량이 많다고 그런 현상이 나타난다는 것도 웃긴 일이고,

문제의 원인을 MySQL일 것이라고 생각하는 것은 더 웃긴 일입니다.

말씀하신 정도의 버그가 있다면, Release되지도 않았을 것입니다.

만약, 버그였다 하더라도 Application 에서 적절한 예외 핸들링을 했다면 

어느정도 Catch는 가능했을 것이라고 생각됩니다.

지금 이 시점에 정확한 원인은 알 수 없지만,

확실한 것은, Application에서 명확한 Transaction이나 예외 핸들링이 되었는지를

먼저 재검토하시는 것이 좋을듯 합니다. 그렇게 했는데도 이런 현상이 나타난다면

Application 코드에 디버깅 코드를 심어서 문제의 원인을 확인하신 후, 

MySQL쪽에 버그 레포팅을 하심이 좋아 보입니다.

어떤 DBMS 벤더도 말씀하신 수준으로 문제의 원인을 해결해줄 수 있는 곳은 없습니다.

이와 비슷한 문제들을 파헤쳐 보면 Application의 코드가 문제였던 경우가 상당히 많습니다.

참고로,

저의 경험을 말씀드리면, 지금까지 MySQL 데이터베이스(특히 InnoDB)가 깨졌다거나 데이터가 손실된 경우는 

최근 3~4년내에 한번도 발생한 적이 없습니다.

그런 DBMS 면 쓰지도 않겟죠..

KT ,SKT 삼성, 관공서 등등 미쳤다고 돈주고 그거쓰겠어여?

아마 다른쪽 문제 같습니다. 그리고 20명 정도가 어느정도

부하주는지 모르겠지만.. 실제 분당 4~5만 쿼리도 아무 문제 없이

잘돌아가고 있습니다.

갑자기 고수님이 나타나신 듯 하여, 구글링해보니 mysqlperformanceblog.com에서 낸 책을 번역하신 이성욱(brew)님이시군요. 반갑습니다! (일단 책부터 사고... )

오오 +_+ 오랜만에 왔더니 이런 고수분을 +_+ㅋ

저도 질러봅니다. ^^ㅋ