>>>If there exists the write conflict, what is the solution? Lock table?
>>>How?
>>
>> Pick one:
>>
>> 1. Put it all in one statement, if possible.
>> 2. Transactions. (Requires InnoDB tables)
>> 3. LOCK TABLE
>>
>> Depending on what you are doing, #1 or #2 are preferable. #3 tends
>> to cause more of a bottleneck than necessary (transactions may lock
>> only part of a table, rather than the whole thing). If part of a
>> transaction fails, the whole thing gets rolled back (all the changes
>> are undone).
>
>Or, quit predetermining your pkey, let MySQL assign it out of an
>autoincrement column, and use the supplied function to ask for the pkey
>when MySQL has finished the insert. There's very seldom a good reason to
>make a primary key contain any information aside from the row's own
>identity.

There *IS* a good reason to predetermine (from user input) a unique
index being used as a user name, "handle", email address (assuming
this site provides one using a single fixed domain name) or whatever.
It makes the site more user-friendly and personal. This probably
isn't a primary key. As you said, an autoincrement primary key is
a good idea. But the user name, "handle" or whatever still needs
to be unique and there's good reason to allow the user to choose
one. It also probably deserves an index, since logging in will
probably use this field rather than the primary key, and if users
can refer to each other via the user interface, they will probably
use this field. So I expect a lot of lookups on it.