
Terrible choices: MySQL (2014) - StreamBright
https://blog.ionelmc.ro/2014/12/28/terrible-choices-mysql/
======
mathnode
I have been a mysql dba for years; I don't recommend mysql for anything or
anyone. Oracle are adding glitter, not polish.

If you still really want or need mysql please do check out mariadb, even old
versions like mariadb 5.3 onwards added a lot of features and fixes for old
problems from before the Sun acquisition (Remember, MariaDB was forked with
the Sun buyout or MySQL AB, not Oracle). It's not entirely a drop in
replacement though, read the manual and test your configs!

What MariaDB/MySQL is still really good at, is scaling horizontally pretty
quickly, just be sure to separate out different schema workloads into
different server instances, and don't make your schema overly complex. Not
that it can get too complex anyway with SQL/PSM heh- _snort snort_.

Want to scale bigger and faster, and maybe with an even more highly tuned
dataset per-cluster? Cassandra. Lots of Oracle and IBM business is being
slurped up by Cassandra and Datastax.

Want mixed database workloads and all the RDBMS management, SQL and PL
goodies? PostgreSQL.

~~~
chris_wot
I'm genuinely curious - under what circumstances would you recommend MySQL or
even MariaDB over PostgreSQL?

~~~
mathnode
Since Streaming Replication and pg_basebackup was introduced in PostgreSQL; I
generally wouldn't.

MariaDB 10 and onwards has some fun features though if you are stuck with it.
The CONNECT and TokuDB storage engines are very useful and interesting.
Parallel, Multi-source, and GTID replication with multiple domains is very
easy.

------
edejong
I remember being introduced to MySQL a long time ago (around 2004). When I
noticed its standards incompliance, buggy indexing, weird collating behaviour
and incomplete query optimizer, I was repeatedly told these quirks will soon
be resolved and it was 'only a matter of time'. Something to keep in the back
of your head when you see similar situations with other open source solutions.

~~~
noja
with other <strike>open source</strike> solutions.

~~~
endymi0n
While it most definitely is open source, it nicely shows the difference
between an open source _project_ and an open source _product_ (which, on top,
is cannibalizing the other, ridiculously high priced mainline inhouse DB)

------
onion2k
I'm quite sure you could do a breakdown of _any_ technology and find enough
problems that it looks like a bad choice.

What tech you use is always a compromise between the benefits of what it's
good for and the problems you need to work around. In the case of MySQL it's
ubiquitous across hosting services, easy to use, _very_ fast once you've tuned
it a bit, and there's clients for pretty much every language. You need to
weigh those things against all its problems, and often you'll find it's
_actually_ a good option if you're doing web work that you need to deploy to
environments you have little control over - less so now than 5 years ago
admittedly, but that _is_ the reason MySQL is so popular - because before the
devops trend that's got web teams running their own servers most sysadmins
made MySQL the only database available.

~~~
smt88
> _it 's ubiquitous across hosting services_

So? No one needs 10 different hosting services. You only need one, and you've
been able to choose a (cheap!) one that offers Postgres for many years now.

> _easy to use_

I strongly disagree, and the entire article is basically rebutting this
assertion. It _seems_ easy to use, but silently failing, breaking promises,
and being noncompliant with standards are all issues that make MySQL _harder_
to use.

> _very fast once you 've tuned it a bit_

You can tune Postgres as well. It actually optimizes its queries much better
than MySQL does, so you can go longer without starting to optimize.

> _and there 's clients for pretty much every language_

Unless you're using some fringe-y language, this isn't an issue either. Some
languages have gotten a Postgres client before MySQL, simply because their
communities have a culture that's more similar to Postgres.

------
TazeTSchnitzel
MySQL is the PHP of databases (speaking as a PHP contributor). It's awful in
the same kinds of ways.

~~~
mamon
MySQL does not deserve to be called a database at all - as the article
describes, it does not implement basic database features correctly.

~~~
hughperkins
I think it's fairer to say that: it doesnt necessarily implement them in a
standards-compliant way. Which I dont mean to imply it implements everything,
in a non-standard way, it's missing a bunch of stuff. But it does have a lot
of standard database features, like transactions and so on, but a lot of stuff
is ... odd. for example, 'row_number()' is missing. You have to use session
variables.

~~~
mamon
"Non-standards-compliant way" is the long-time default engine, MyISAM not
supporting transactions and locking. Fortunately they moved to InnoDB as
default recently, but the very fact that it took them so long tells much about
their attitude towards DB standards compliance.

------
spacemanmatt
Article is from 2014; does all of this still apply? I'm just trying to
understand the relevance, other than MySQL is a flaming death trap which
everyone should be warned about regularly.

~~~
kidmenot
I would be happy to be proven wrong (thankfully I have dealt exclusively with
Postgres in the last two years or so), but I think most of the warts and
shortcomings the post talks about are still extant.

Off the top of my head, I can add that you can't have subselects in views
(which is preposterous), nor can you materialize views. Also, I don't believe
you can have function-based indexes, and most certainly you can't pivot tables
easily and CTEs are not supported.

I think 5.7 (if it's been released) finally brought the ability to create
multiple triggers for the same event. Until 5.6 you could specify only one.

In short: MySQL is no fun. Choose Postgres or any other decent system, but
just steer clear of the damn dolphin.

~~~
spacemanmatt
> MySQL is no fun. Choose Postgres or any other decent system, but just steer
> clear of the damn dolphin.

Ahahahahahahaha. Thank you. That was amusing and also helpful.

------
mediascreen
For anyone that still wants/has to use MySQL, there is always MariaDB - a drop
in replacement that is evolving a bit faster.

[https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-
features/](https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-features/)

~~~
1812Overture
Whoa there. Not completely drop in. Definitely thoroughly go through the
documentation to see where MariaDB has diverged from MySQL over the years.

------
chris_wot
Even though this is an old article, I stumbled on pgloader!

[http://pgloader.io/](http://pgloader.io/)

Sounds like this might get me out of future MySQL pain...

~~~
smt88
I used pgloader for a project, and it was harder to use (and lossier) than I
was expecting. Make sure you carefully look what you're losing in the
conversion and are able to add it back (either during conversion by hooking
into pgloader or after conversion).

~~~
chris_wot
Do you have any further details on what you lost? Very curious - especially to
know if it would be considered a bug or design flaw somewhere in the program
itself, or a feature mismatch between MySQL and PostgreSQL.

~~~
smt88
Feature mismatch. Something related to constraints. It wasn't a showstopper at
all.

------
lucian1900
So the solution to making get_or_create work is to downgrade the isolation
level? That seems like the flaw is with get_or_create in the first place.

I've found collisions to be quite nice for doing "upserts", either on a
constraint or predictable id.

------
eterm
Without wanting to discuss the merits of MySQL (I don't use it), is case
insensitive collation that much of a problem?

I note that case insensitive collation is also a default for MS-SQL.

~~~
chris_wot
It's not just case-insensitive, it's _accent_ insensitive. That could cause
problems for any language that uses accents.

