Hacker News Reader

Comment by cincinnatus | Hacker News Reader

MySQL is richly deserving of ridicule as well. It's ubiquity is unfortunate.

If you're going to comment so strongly, some explanation of why it deserves such ridicule would contribute much more value to the discussion.

No check constraints. Spotty transaction isolation. Silent data corruption if you happen to make certain kinds of updates while using statement-based replication. No on-line schema updates (is that still true?). Complete inability to execute joins of any size in reasonable time due to the lack of merge or hash join strategies. Corresponding inability to handle subqueries of any complexity. Readers block writers (at table level with MyISAM - and still at row level with InnoDB?).

As well as things like that which are actually ridiculous, there is also the substantial gap in features as compared to real databases. Things like recursive queries, user-defined types, partial indices, etc, are commonplace in the more sophisticated databases. You probably won't need them for a simple web application (or even a complex one!), but they can be very useful when trying to do more complex things, or manage a complex system efficiently.

I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions.

I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.

Just ran into this link, which seems to describe how MVCC can sometimes not be enough.

http://ronaldbradford.com/blog/understanding-innodb-mvcc-200...

Having read through it, I rather suspect that that's not a matter of writers blocking readers or the other way round, but instead a case of writers blocking writers - he's writing a lot of data to the table, and it's highly likely that InnoDB has escalated the lock to a table lock - which effectively prevents concurrent writes.

I don't believe that InnoDB escalates locks. Quoting from the fine manual:

http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-mo...

> InnoDB does locking on the row level and runs queries as nonlocking consistent reads by default, in the style of Oracle. The lock information in InnoDB is stored so space-efficiently that lock escalation is not needed: Typically, several users are permitted to lock every row in InnoDB tables, or any random subset of the rows, without causing InnoDB memory exhaustion.

Readers blocking writes may have been changed in a never version than what we use, but it still exist in at least some versions of 5.x.

My apologies - you're right. In the general case readers don't block writes, but InnoDB does use share locks on some foreign key interactions and when using the SERIALIZABLE isolation level.

Besides the corruption, that just sounds like it's missing features. Missing features is ridicule worthy?

It can be when you look at how long people have been asking for these things.

When the "feature" is a basic property of a relational database - as check constraints and efficient joins and subqueries are - then yes.

Reply on news.ycombinator.com