결론적으로 벤치마크 힘듭니다.

ODBC, JDBC, 네이티브 프로토콜을 사용했느냐에 따라 속도가 천차만별입니다.

MS-SQL의 경우 JDBC드라이버 문제로 유독 자바쪽에서는 성능이 약하지만 자사의 OLEDB같은 경우 환상적인 속도를 보여줍니다.

또 데이타량이나 SQL쿼리의 복잡도에 따라서도 옵티마이저에 따라서 다른 결과를 보여줍니다. 이러한 옵티마이저의 판단에 영향을 미치는 요소도 너무 다양해서 색인이나 클러스터링 여부, 통계정보의 수집 정도에 따라서 모두 다른 결과를 가져옵니다.

잠금처리도 모두 다릅니다. MySQL은 테이블단위 잠금 밖에 처리 안하므로 동시 DML이 많다면 속도가 치명적일 수 있습니다.

MS-SQL은 select 도 잠금이 걸리기도 하던데... 오라클 같은 경우는 select 는 기본적으로 잠금이 걸리지 않습니다.

또 MySQL은 테이블 파티셔닝이나 클러스터드 인덱스 같은 것들이 지원이 안되고 있으므로 대용량 DB에서는 못쓸겁니다.

제 소견으로 벤치마크는 제쳐두시고 각 DBMS 엔진의 특성을 잘 파악해서 최적의 SQL을 작성하고 관계형 DBMS의 기본을 익혀서 잘 사용하는게 중요한 것 같네요. 그러고 나서도 DBMS 엔진의 기능에 한계를 느낀다거나 옵티마이저의 최적화가 마음에 들지 않는다면 다른 DBMS엔진을 써야겠지요.

설령 납득할만한 환경으로 벤치마크를 수행했다고 하더라도 각 DBMS의 전문가가 튜닝하고 나면 또 결과가 달라질겁니다.

그래서 벤더들도 모든 벤치마크를 인정하지 않고 허용하지 않습니다.

MySQL과 MS-SQL의 경우 MySQL이 비교적 적은 데이타량에서 환상적인 동시접속 처리 능력과 성능을 보여주긴하지만... 기능면이나 대량의 데이타처리 기능등에서는 MS-SQL과 직접 비교하기에는 좀 그렇네요.

그리고 주로 처리량이 많고 속도가 느린 DW나 통계성일 때 영향을 많이 주는게 조인능력인데... MySQL이 어떤 join method를 지원하는지는 모르겠네요. nested loop만 지원하고 Sort merge나 hash join 기능은 없을 것 같은데... 처리 범위가 넓은 조인 수행하면 엄청나게 느린 속도를 보여줄겁니다.

따라서 MySQL은 주로 중소규모의 웹환경등의 OLTP성 업무에 적합해보입니다.

그리고 DBMS선택 기준에 성능이 1순위는 아닙니다. 플랫폼에 따라서도 다르고... 개발환경의 편이성 혹은 비용, 안정성, 사용하는 패키지에 따라서도 다릅니다.