Some rephrasing, based on suggestions by Egor.

@cindex rows, locking

@cindex locking, row-level

Generally, you can code around row-level locking. Some cases really

need it, but they are very few. For instance, you can use a flag

column in the table and do something like this:

You can generally code around row-level locking. Some situations really

need it, but they are very few. @code{InnoDB} tables support row-level

locking. With MyISAM, you can use a flag column in the table and do

something like the following:

@example

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

@cindex methods, locking

Currently MySQL only supports table locking for

@code{ISAM}/@code{MyISAM} and @code{HEAP} tables.

@code{InnoDB} tables use row level locking,

and @code{BDB} tables page level locking. @xref{Internal locking}.

With @code{MyISAM}

tables one can freely mix @code{INSERT} and @code{SELECT} without locks

(@code{Versioning}).

@code{ISAM}/@code{MyISAM} and @code{HEAP} tables,

page-level locking for @code{BDB} tables and

row-level locking for @code{InnoDB} tables.

@xref{Internal locking}.

With @code{MyISAM} tables one can freely mix @code{INSERT} and

@code{SELECT} without locks (@code{Versioning}).

Starting in version 3.23.33, you can analyse the table lock contention

on your system by checking @code{Table_locks_waited} and

@code{Table_locks_immediate} environment variables.

Some database users claim that MySQL cannot support near the

number of concurrent users because it lacks row-level locking.  This

may be true for some specific applications, but is not generally

true. As always this depends totally on what the application does and what

is the access/update pattern of the data.

To decide if you want to use a table type with row-level locking,

you will want to look at what the application does and what the

select/update pattern of the data is.

Pros for row locking: