E.g., the following used to be a statement in MySQL, at the time I used it; I presume it still is:

  CREATE KEY …

It is the primary form of this alias:

  CREATE INDEX

which is what the command does (it creates an index; it does not "create" a "key".) But since the form of the command with the correct words is itself an alias, the wrong form gets output any time MySQL self-describes something, generating endless confusion from people thinking a set of columns are a key, when they actually may or may not be. (They might also be a key, but index does not imply key.)

> struggled with functional dependencies

E.g., in GROUP BYs:

  SELECT a FROM table GROUP BY b;

where a is not a functional dependency of b. (The statement is thus nonsense.) MySQL will permit this statement to execute, and generate undefined results for column `a` in the output.

In the day I used it, UTF-8 was not the default (the default was latin1, IIRC). Even better, the "utf8" encoding wasn't UTF-8. It was like UTF-8 except where it wasn't. Generated endless numbers of "ah crap, this table/DB isn't UTF-8 and will need a migration."

Simple date math in SELECTS would result in idiocy. (The output of SELECT date_a - date_b was something like "stringify the dates, remove the hyphens, cast to int, subtract" — yes, that sounds crazy, but yet that was a bug I had to work out once. There's a separate DATEDIFF function or something to do the right thing, but the point is that the naïve thing neither errors nor does anything sensible.)

Schema changes escaped from transactions.