http://gywn.net/2013/02/mysql-innodb-auto-increment/
위와같은 문제가 있다고 하네요.. ^^

다른 테이블들은 저런 문제가 발생할 수 있다는 사실이 널리 알려지기 전에 정의되었는지도 모르죠.
잉끼님이 알려주신 문제도 FK 조건을 걸어놓으면 더이상 문제가 되지 않는데,
그누보드는 FK를 사용하지 않으니까...

대략 22년 전 쯤인 거 같습니다.
제가 DBIII+로 코딩을 시작 했을 때 이 문제를 처음 접했습니다.
그 후에 볼란드의 클리퍼라는 DB 언어로 프로그래밍 할 때도 이런 문제가 있다는 걸 알았습니다.
15년 전까지만 해도 저는 도스와 윈도 프로그래밍만 했었는데 VB나 파워빌더에서 자주 사용하는 액세스에서는 이런 increment 문제가 있는지는 몰랐지만 그 때만해도 멀티 유저 기반의 프로그래밍이 아니라서 크게 신경쓰지는 않았습니다.
당시에 마소였는지 다른 잡지였는지는 모르겠지만 이게 스케줄링을 관리하는 OS의 문제와 무관하지 않다는 내용이였습니다.
우리하 흔히 알고 있는 RR 방식의 스케줄링을 타임쉐어링으로 할 것인지 프로세스 단위로 할 것인지에 따라 이런 문제가 생길 수 있다고 했습니다.
OS가 이런 문제를 완벽히 처리해 주지 않기 때문에 트랜젝션을 사용하는데 여기서 이런 increment 문제가 생기는 것이죠.
제가 웹프로그래밍(멀티 유저가 기본)을 처음 시작 할 때, 정확히는 MySQL이란 걸 처음 사용 할 때 primary key에 auto_increment을 사용하는 게 맞는 건지 정말 오래 고민을 했었네요.
결론은 남들도 다 그렇게 하니 지금도 남들처럼 하고는 있습니다. ㅎㅎ
지금도 사실 그렇지만 저는 timestamp도 완전히 믿지는 못하고 있습니다. 약간 노이로제같은...
옛날에 쇼핑몰 만들 때도 timestamp와 난수, auto_increment, IP까지 최대한 조합해서 유일키를 만들어 내는 생쇼를 했더랬죠.