컴파일러는 gcc 2.95를 썼습니다. MySQL은 어제 나온 3.23.51 버젼이고
레드햇 7.2에 커널은 2.4.18을 사용했습니다.
 gcc 2.96이나 3.0은 아직 추천하지 않더군요.
특히 MySQL AB측에서 2.96의 경우 랜덤 크래쉬나 테이블 깨짐 현상이 일어날 수 있으니 사용을
 금하라고 되어있습니다.  테스트 방식은 간단한 innodb 타입의 테이블을 생성하고 PERL을 이
용하여 트랜잭션을 건다음 100만건을 모두 insert한 후 commit하도록 하였습니다.
 create table innodb ( one int primary key, two char(10), three char(30)) type=innodb;
 사용한 PERL DBI프로그램 코드 
 $dbh->do("set autocommit = 0");
  for ($j = 0; $j < 1000000; $j = $j + 1) {
   $dbh->do("insert into innodb values ($j, '$j', '$j')");
}
 $dbh->do("commit");
 $dbh->disconnect;
 결과는
 [root@localhost download]# time ./bench.pl
 real    1m49.544s
user    0m22.770s
sys     0m10.470s
  MyISAM타입의 테이블에도 동일한 테스트를 해봤습니다.
[root@localhost download]# time ./bench.pl
 real    1m55.493s
user    0m21.550s
sys     0m10.370s
  bulk insert의 경우 innodb가 오히려 트랜잭션을 걸고도 더 빠른 기현상이
발견되었습니다.
 100만건 트랜잭션 처리에 저 정도면 나쁘지 않다고 생각되는군요. :-)
  -------------------------------------------------------------
참고 사항:
 MyISAM bulk insert의 성능을 올리기위해서
insert 전에 write lock 을 걸고 insert 후 unlock tables를 해주니
innodb보다 빨라지기는 했습니다.
lock을 사용한 결과는
 [root@localhost download]# time ./bench.pl
 real    1m41.498s
user    0m21.460s
sys     0m9.390s
    :
:  MySQL 에서 트랜잭션은 innodb 와 같은 것들을 사용하여 가능하다는
:
:  것은 아마 다들 알고 계실겁니다.
:
:  하지만 매우 복잡한 문제들이 많이 있습니다.
:
:  역시 뻔한 이야기 이지만.... MySQL 로 운용 가능한 대형 싸이트 라는
:
:  조건하에... 트랜잭션 사용을 위해 innodb 로 바꾼 결과
:
:  끔찍한 일들이 벌어지곤 합니다.
:
:  사실 MySQL 이 개발되어진 근본적인 이유를 짚고 넘어가자면...
:
:  MySQL 에서 트랜잭션을 원하는것 자체가 좀 문제가 있지
:
:  않을까... 싶습니다.
:
:  어쨌든... 예전 방법대로 그냥 다시 사용하고 있습니다.
:
:  이번기회에 PostgreSQL 로 옮길 생각도 하고 있습니다.
:
:  제가 잘 몰라서... 그게 과연 효과가 있을지는 모르겠지만...