5 ms·

The author's assertion that "Another problem with MySQL is that any table modification (e.g. adding a column) will result in the table being locked for both rea

The author's assertion that "Another problem with MySQL is that any table modification (e.g. adding a column) will result in the table being locked for both reading and writing. This means that any operation using such a table will have to wait until the modification has completed." is no longer correct as of Mysql 5.6: http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-o... If you specify ALGORITHM=INPLACE,LOCK=NONE you can alter table without blocking reads and writes. We have used this method successfully in Amazon RDS when updating schemas.

troels 12y ago
It's not exactly a common operation either, so basing the choice of rdbms on it seems a bit arbitrary.
- jeltz 12y ago
  It happens a couple of times every month in our production databases. If it required locking tables we would have to schedule downtimes during the early mornings every time this happens would would have been a pain.
morgo 12y ago
Small clarification: > If you specify ALGORITHM=INPLACE,LOCK=NONE you can alter table without blocking reads and writes. We have used this method successfully in Amazon RDS when updating schemas. The use-case of ALGORITHM=INPLACE and LOCK=NONE is to produce an error if the modification you are attempting is not supported in this mode. i.e. even if you don't specify LOCK=NONE, that doesn't mean it will lock. This is useful in preventing guessing games (i.e. you think its LOCK=NONE, but for some reason it's not compatible...)