Slashdot Mirror

Try --create-options:
http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_create-options

mysqldump by default aims to dump valid SQL for any DB (which is why the MySQL-specific options are within special comments). The ENGINE= attribute of the CREATE TABLE query is MySQL-specific so left off by default, --create-options should include it.

Thanks - that's a good explanation.

However, I just tested it and it didn't work.

A-ha! I was using --compatible=ansi and that was the issue.

Thanks again for pointing me in the right direction.

"Duh"

CREATE TABLE `test` (
    `kkeeyy` int(11) NOT NULL AUTO_INCREMENT,
    `a` varchar(10) DEFAULT NULL,
    `b` varchar(10) DEFAULT NULL,
    PRIMARY KEY (`kkeeyy`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

If you're running MySQL as root, you are doing it wrong.

Note that those comparisons are with MySQL 5.5.
MySQL 5.6 is supposed to have performance improvements over 5.5 that should make it competitive with Percona Server, particularly on machines with many cores. Percona will also incorporate these changes.

MariaDB is farther from mainline, and merging in the changes that are applicable to them will take longer.

Also, some (almost all?) ODBC and database servers send passwords in the clear.

Many database servers allow encrypted passwords, but there are surely a lot of database installations that don't take advantage of it. In PostgreSQL you can use SSL for the client network connection, which ODBC passes through. Setup SSL as the only way to connect, and encryption has to happen before it hits the wire. MySQL has a similar trick. Both are just using the OpenSSL library under the hood to encrypt the network traffic.

On the commercial side, Oracle does the same thing with ORA_ENCRYPT_LOGIN. SQL Server has client and server settings that enforce encryption. Basically, if your database traffic isn't encrypted, it's more likely because someone didn't think that was important than because it was impossible. It's a simple checkbox to add to database selection requirements, and it's not hard to find a DBMS that has the capability.

I find people who just stuff user passwords into the database (which can be the same passwords as other services) rather than putting password encryption into their application can also leak data. In PostgreSQL using the built-in pgcrypto makes that easy. You also have to be careful to use the same network encryption approach for any replication client, or it's possible to just sniff that instead to get the data. In Postgres those connect with the same encryption possible options as any other client. Most of the tutorials on setting up replication don't cover this though.

Another person my boss reports to believes mysql is not a professional database server.

As long as ALLOW_INVALID_DATES is built into MySQL, it will never be a professional database server.

free = not professional

They'll be more than happy to sell you a support contract if your organization really wants to throw money at them for hand-holding.

Well, I'd like to inform you that the video is crap. My summery of the video: "I don't know how to configure my software properly, so rather than claim that my knowledge is crap, I'll claim the software is crap instead". Not sure what I'm talking about? Here:

http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html#sqlmode_strict_all_tables

For what MySQL is used for 99% of the time, I find the default behavior to be more desirable than the strict behavior, and I suspect most people do too, which is why non-strict mode is the default. But if you want it to behave differently, by all means, configure it the way you want.

Of course, most of the posters here would rather just bash MySQL and remain ignorant rather than inform themselves of how to properly configure it.

They will never give the answer on the forum. They will always ask you to contact them offline.

Which means of course that it's all GPL, and you can use it all freely under the terms of the GPL license, and they don't want to tell you that on the forum, probably because they believe it will impact their revenue.

Actually, they do tell you that here:

Our software is 100% GPL (General Public License); if yours is 100% GPL compliant, then you have no obligation to pay us for the licenses. This is a great opportunity for the open source community and those of you who are developing open source software.

Their developers suck. Go look at the sort of bugs MySQL gets, AND gets AGAIN.

MySQL is the PHP of databases.

Example: http://bugs.mysql.com/bug.php?id=31001

Notice the part where the bug is reintroduced. If they require regression tests to pass before releases this bug would not happen again.

Well, if they sell licenses for it, they're keeping it a big secret. Go to the http://www.mysql.com/products/enterprise/>EE web page and click on "Buy Now". How many licensing options do you see? They're all support contracts.

They could have killed MySQL long ago by revoking the InnoDB license (we all know MyISAM is shit).

And let's not forget that Oracle didn't buy MySQL, they bought Sun. I work or a company that uses Oracle DBs and I can assure you - they were after the hardware assets. ExaData is INSANELY expensive (like > $500,000 expensive).

They probably keep MySQL alive so that they can still gouge customers who can't afford Oracle-grade gouging. (Oracle is $17,500, MySQL is only $5,000)

MXJ includes MySQL for several OSs (windows, x86, osx, solaris) and installs MySQL automatically. in all it's 130MB jar, /J is just MySQL driver for Java (4MB). Itried searching forums and found this - http://lists.mysql.com/java/9354, someone complaining about missing MXJ.

Dunno. Hadn't heard anything about it being pulled, although I notice the last release was about 18 months ago. Are you sure that functionality's not in Connector/J now?

You might try asking on their forums about it.

I've downloaded it as recently as 2 months back, and found it gone yesterday. The download page at http://dev.mysql.com/downloads/connector/mxj/ is empty and mxj connector is no longer listed under connectors - http://dev.mysql.com/downloads/connector/. SQLite aside, MXJ was the easiest way to embed a MySQL database in your (Java) package.

I've downloaded it as recently as 2 months back, and found it gone yesterday. The download page at http://dev.mysql.com/downloads/connector/mxj/ is empty and mxj connector is no longer listed under connectors - http://dev.mysql.com/downloads/connector/. SQLite aside, MXJ was the easiest way to embed a MySQL database in your (Java) package.

I've downloaded it as recently as 2 months back, and found it gone yesterday. The download page at http://dev.mysql.com/downloads/connector/mxj/ is empty and mxj connector is no longer listed under connectors - http://dev.mysql.com/downloads/connector/. SQLite aside, MXJ was the easiest way to embed a MySQL database in your (Java) package.

That said, little things like having to use WHERE ROWNUM = X, rather then LIMIT which basically always requires a subselect to get correct results is just annoying and makes our code less portable.

One of the sad parts of SQL is that row limiting (to my knowledge) isn't part of the standard. So, unless a database explicitly adds support for another database's syntax it doesn't happen.

For example, from the MySQL docs:

For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax.

Until MySQL 4, MySQL's LIMIT command was LIMIT x,y which was the equivalent of Postgres's LIMIT y OFFSET x.

otherwise the first method would have been fixed rather than "replaced".

That is directly from the mysql API. http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html

Make of it what you will.

You can run MySQL Cluster on two machines. It's somewhat complex to set up. And your POS terminals have to be able to connect to either server. But it's available.

If you're getting more than one crash a year, you have hardware problems. Commodity hardware may be unsuitable for a restaurant environment. You may need an industrial-grade PC, with a broad operating temperature range and resistance to dirt, dust, grease, and water. There are PCs and enclosures for restaurants, and the fast-food industry uses them extensively. Every McDonalds, Burger King, and KFC outlet uses industrial-quality POS systems.

You wouldn't use a home-quality stove or a home-quality coffee maker in a restaurant. It wouldn't hold up. The same goes for a computer.

Well MySQL is crap. No surprise SQL Server looks great compared to MySQL.

It's a got a nice feature set on paper which impresses the bosses, but you can't use all of them at the same time. You want X that means you need backend P, which means you can't have Y which needs backend Q. You can run both backends, but then stuff using the backend that doesn't support transactions isn't rolled back...

And it's not reassuring when they can allow bugs like these out the door:
http://bugs.mysql.com/bug.php?id=31001
http://bugs.mysql.com/bug.php?id=32202
Note the similarity between #31001 and #32202 AND that the #31001 bug reappeared a year later!

MySQL is the PHP of databases. Both products seem to be produced by developers who are working on something that is beyond their expertise.

But yeah SQL Management Studio is nice. FWIW psql is decent for a cli, though of course it's not as sophisticated.

Well MySQL is crap. No surprise SQL Server looks great compared to MySQL.

It's a got a nice feature set on paper which impresses the bosses, but you can't use all of them at the same time. You want X that means you need backend P, which means you can't have Y which needs backend Q. You can run both backends, but then stuff using the backend that doesn't support transactions isn't rolled back...

And it's not reassuring when they can allow bugs like these out the door:
http://bugs.mysql.com/bug.php?id=31001
http://bugs.mysql.com/bug.php?id=32202
Note the similarity between #31001 and #32202 AND that the #31001 bug reappeared a year later!

MySQL is the PHP of databases. Both products seem to be produced by developers who are working on something that is beyond their expertise.

But yeah SQL Management Studio is nice. FWIW psql is decent for a cli, though of course it's not as sophisticated.

Looks a whole lot like table level locking to me.

MySQL uses table-level locking for MyISAM, MEMORY and MERGE tables, page-level locking for BDB tables, and row-level locking for InnoDB tables.

http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html

MongoDB can write its data to /dev/nul/ for extra performance.

Just so you know, so can MySQL

http://dev.mysql.com/doc/refman/4.1/en/blackhole-storage-engine.html

The default engine, MyISAM, is by design a non-transactional engine. BY DESIGN. If you want transactions you have to use InnoDB. It has always supported booleans, that i've seen. bool/boolean is the same as tinyint(1). 0==false, anything non-zero is true.

https://dev.mysql.com/doc/refman/5.5/en/other-vendor-data-types.html
https://dev.mysql.com/doc/refman/5.0/en/storage-engines.html

The default engine, MyISAM, is by design a non-transactional engine. BY DESIGN. If you want transactions you have to use InnoDB. It has always supported booleans, that i've seen. bool/boolean is the same as tinyint(1). 0==false, anything non-zero is true.

https://dev.mysql.com/doc/refman/5.5/en/other-vendor-data-types.html
https://dev.mysql.com/doc/refman/5.0/en/storage-engines.html

Facebook is MORE efficient than Craigslist. Craigslist has 28 employees serving 1 billion pages/month.

Facebook has 3500 employees serving 1 trillion pages/month

Craigslist: 35.7 million pages/employee
Facebook: 285.7 million pages/employee

So how does that contradict my point? Huge websites are not free or cheap.

There are one-way encryption methods (for example, MD5, SHA1) which only allow you to encrypt a string, but not decrypt it. There are also two-way encryption schemes (allows encryption and decryption), like AES Encryption. If I had to store data which could identify users or credit card information, I would look into two-way encryption mechanisms (those which can be both encrypted and decrypted).

More info on using AES to store credit card info.

The theory behind these algorithms is quite involved, but the programming interfaces to use them are very simple. A developer should take 60 minutes to learn about them, first out of respect for the users, and second, to avoid ending up in the news.

Facebook should just switch to writing to /dev/null for the best possible performance...

Now that you mention it, MySQL has had this option for years.

Actually, mysql_real_escape_string() is originally from MySQL's C API. Which just goes to show that MySQL is just as shitty as PHP.

You do know that MySQL has a BLACKHOLE storage engine that lets you do pretty much that, right?

You're probably right, but that's not what this release is referring to. The NDBCLUSTER engine separates "API" nodes from Data nodes. A server running MySQL with NDBCLUSTER enabled is considered an API node, but you can also have a C++ or Java or whatever API node that isn't MySQL. Data nodes are provisioned in one or more "node groups" with one or more data nodes in each group, though it would be dumb to have a single node group or a single node in a node group. Each node group splits the data somehow. You can force tables to exist on just one group, but by default if you have three node groups you would have approximately a third of your data in each group.

Anyway -- prior to NDBCLUSTER 7.2 if you performed any join whatsoever the API node had to pull the complete tables from all data node groups prior to doing the join on itself and returning the result. This made join performance, simply put -- terrible. I've tested the same query on a standalone out of the box mysql server against a 7.1 cluster and had an 8 second query come back from the cluster in several minutes due to the join performance.

NDBCLUSTER 7.2 adds what was called "push down joins" in development -- basically the data nodes now do the joins within their own sub-sets of the data for certain joins resulting in a dramatic improvement in performance, since now the API nodes just get the result from the network instead of the entire dataset.

It really is an amazing improvement and is a result of the dynamic capabilities of MySQL. NDBCLUSTER was never designed for the type of data people are throwing at it, and with the recent improvements it might actually be viable for use on production web sites for more common usage scenarios.

What I do not see addressed yet with 7.2 is the reload time -- if you have a cluster loaded with several GB of data it can take upwards of 20 minutes to reload the data and indices across the cluster. While the cluster is designed to be up 24x7 (even through upgrades), a single bug or memory error that takes it down can result in a prolonged outage. There are several of these open in the bug tracker.

You're probably right, but that's not what this release is referring to. The NDBCLUSTER engine separates "API" nodes from Data nodes. A server running MySQL with NDBCLUSTER enabled is considered an API node, but you can also have a C++ or Java or whatever API node that isn't MySQL. Data nodes are provisioned in one or more "node groups" with one or more data nodes in each group, though it would be dumb to have a single node group or a single node in a node group. Each node group splits the data somehow. You can force tables to exist on just one group, but by default if you have three node groups you would have approximately a third of your data in each group.

Anyway -- prior to NDBCLUSTER 7.2 if you performed any join whatsoever the API node had to pull the complete tables from all data node groups prior to doing the join on itself and returning the result. This made join performance, simply put -- terrible. I've tested the same query on a standalone out of the box mysql server against a 7.1 cluster and had an 8 second query come back from the cluster in several minutes due to the join performance.

NDBCLUSTER 7.2 adds what was called "push down joins" in development -- basically the data nodes now do the joins within their own sub-sets of the data for certain joins resulting in a dramatic improvement in performance, since now the API nodes just get the result from the network instead of the entire dataset.

It really is an amazing improvement and is a result of the dynamic capabilities of MySQL. NDBCLUSTER was never designed for the type of data people are throwing at it, and with the recent improvements it might actually be viable for use on production web sites for more common usage scenarios.

What I do not see addressed yet with 7.2 is the reload time -- if you have a cluster loaded with several GB of data it can take upwards of 20 minutes to reload the data and indices across the cluster. While the cluster is designed to be up 24x7 (even through upgrades), a single bug or memory error that takes it down can result in a prolonged outage. There are several of these open in the bug tracker.

MySQL does have spatial feature support. The underlying data structure can do point-in-rectangle tests cheaply. More complex geometry is supported, but the query engine will generally construct a bounding rectangle for index lookup purposes, then sequentially test the hits against the more complex geometry.

I've tried this, and it does work. It's good enough for efficient "all gas stations within N miles of here" queries, for example.

Corrupted MyISAM Tables after a crash are expected from MySQL when using that storage engine; that's the only sort of incident I can think of here that could rightly be attributed to that database. slashdot converted to Innodb a long time ago though. The downthread griping sounds like it could just as easily be a caching issue above the database instead, given there's multiple layers of that going on.

How about Netlib? Wait, they have a library for statistics and not statistics for a library.

Ultimately, you are a librarian and not a statistician. If you have a background in mathematics that includes statistics, then you might be able to use the "better" products. The problem, though, is that the person interpretting the results will also require an understanding of what the pretty charts mean. It seems unreasonable to send people to a statistics course to understand the kind of data you are collecting.

I do not know how the statistics are being stored or calculated now. If there is a database involved, most of those can do basic statistics directly in the query.

The more in-depth statistics programs are often used by people who want to spend large amouns of time analyzing data. Though they can produce standard charts quickly, it often takes a bit of exploring for a way to convey the desired message.

"Figures don't lie, but liars figure." - Mark Twain

InnoDB has been added in 2001. Replication has been there since forever. You're listing old features of MySQL, not additions done by Oracle.

InnoDB becomes the default storage engine in MySQL 5.5, a non-trivial change from earlier versions (where MyISAM was the default).

Semi-synchronous replication is a new feature of replication in MySQL 5.5.

All of the other features mentioned by the AC are also either new or singificantly changed in 5.5.

InnoDB has been added in 2001. Replication has been there since forever. You're listing old features of MySQL, not additions done by Oracle.

InnoDB becomes the default storage engine in MySQL 5.5, a non-trivial change from earlier versions (where MyISAM was the default).

Semi-synchronous replication is a new feature of replication in MySQL 5.5.

All of the other features mentioned by the AC are also either new or singificantly changed in 5.5.

No foreign keys

You mean just like MyISAM? It has it's [sic] uses.

If we grant that a substantial set of use cases where a full-scale, non-embedded, out-of-process database is called for but relational integrity is unimportant exist (something I grant only for the sake of the ongoing argument), that still leaves people who try to use it in situations outside that set. I once took maintainership of an accounting system for car dealerships built on top of a "database" without relational integrity. Cases where bugs in the software resulted in orphaned records and numbers that didn't add up were legion.

Saying you don't need relational integrity is right up there with saying you don't need bind variables because your hand-built escaping code is good enough. There might be cases where hand-built escaping is good enough, but encouraging J. Random Slashdot Reader to take that approach means it's going to be abused... and I assure you, the person who built that accounting system considered himself an expert.

no guarantees of that data has been flushed to disk when a COMMIT comes back

It uses a two-phase commit process.

Interesting documentation. Reading the links -- suffice to say that MySQL's multi-master clusters are vastly less safe than Oracle RAC. Depending on after-the-fact conflict resolution rather than having proper locking... really? (And with respect to NDB not supporting fsync() before reporting a commit complete -- yes, I can provide a link for that. Being in a cluster isn't good enough -- sometimes you lose a rack, or a full DC).

Yes, it's cheaper. Yes, it might be good enough for someone. But if someone needs RAC features enough to pay $50K in licensing fees for a tiny cluster, NDB just ain't gonna' cut it. And if I'm handling medical data (which I was last time I deployed RAC), I'm not going to risk massive liability by deciding that I can afford to get a COMMIT back before data is not just ACKed by multiple nodes but sitting on a platter.

PostgreSQL 9.1's synchronous streaming replication is a sane middle ground -- it's not multi-master, but it actually preserves the same semantics and performance characteristics (durability semantics being the most critical of those -- but at the same time, needing to rewrite everywhere your code uses savepoints or autoincrement or relies on referential integrity exceptions because you're switching to a database backend that doesn't support them isn't any fun either) you'd have in a non-clustered environment. Having it available six years ago would have saved me one helluva lot of money.

Provided whomever sets the cluster up knows what they are doing and doesn't half-ass it, it works just fine.

Really? Compared to RAC, wherein moving to a cluster involves no loss of semantics, using NDB looks a whole lot like half-assing it already.

No foreign keys

You mean just like MyISAM? It has it's [sic] uses.

If we grant that a substantial set of use cases where a full-scale, non-embedded, out-of-process database is called for but relational integrity is unimportant exist (something I grant only for the sake of the ongoing argument), that still leaves people who try to use it in situations outside that set. I once took maintainership of an accounting system for car dealerships built on top of a "database" without relational integrity. Cases where bugs in the software resulted in orphaned records and numbers that didn't add up were legion.

Saying you don't need relational integrity is right up there with saying you don't need bind variables because your hand-built escaping code is good enough. There might be cases where hand-built escaping is good enough, but encouraging J. Random Slashdot Reader to take that approach means it's going to be abused... and I assure you, the person who built that accounting system considered himself an expert.

no guarantees of that data has been flushed to disk when a COMMIT comes back

It uses a two-phase commit process.

Interesting documentation. Reading the links -- suffice to say that MySQL's multi-master clusters are vastly less safe than Oracle RAC. Depending on after-the-fact conflict resolution rather than having proper locking... really? (And with respect to NDB not supporting fsync() before reporting a commit complete -- yes, I can provide a link for that. Being in a cluster isn't good enough -- sometimes you lose a rack, or a full DC).

Yes, it's cheaper. Yes, it might be good enough for someone. But if someone needs RAC features enough to pay $50K in licensing fees for a tiny cluster, NDB just ain't gonna' cut it. And if I'm handling medical data (which I was last time I deployed RAC), I'm not going to risk massive liability by deciding that I can afford to get a COMMIT back before data is not just ACKed by multiple nodes but sitting on a platter.

PostgreSQL 9.1's synchronous streaming replication is a sane middle ground -- it's not multi-master, but it actually preserves the same semantics and performance characteristics (durability semantics being the most critical of those -- but at the same time, needing to rewrite everywhere your code uses savepoints or autoincrement or relies on referential integrity exceptions because you're switching to a database backend that doesn't support them isn't any fun either) you'd have in a non-clustered environment. Having it available six years ago would have saved me one helluva lot of money.

Provided whomever sets the cluster up knows what they are doing and doesn't half-ass it, it works just fine.

Really? Compared to RAC, wherein moving to a cluster involves no loss of semantics, using NDB looks a whole lot like half-assing it already.

By "MySQL Cluster", you're referring to the configuration that requires NBD, right?

Yes. This is a bad thing? Properly setup NBD is hard to kill. No data lives in once place.

No foreign keys

You mean just like MyISAM? It has it's uses. This is a cluster, remember. The cluster management nodes are supposed to make this a non issue. As below, as long as someone who knows what they are doing builds it and doesn't half-ass it, this is fine.

no guarantees of that data has been flushed to disk when a COMMIT comes back

It uses a two-phase commit process. Provided whomever sets the cluster up knows what they are doing and doesn't half-ass it, it works just fine.

"REPLACE INTO" is NOT insert/update. it is insert and delete if there's a duplicate.
http://dev.mysql.com/doc/refman/5.6/en/replace.html

If you want insert/update on mysql you use this: http://dev.mysql.com/doc/refman/5.6/en/insert-on-duplicate.html

There is a difference between updating if there's a duplicate and deleting and inserting if there's a duplicate. The differences might cause pain :).

The Postgresql bunch appear to be working on implementing MERGE instead:
http://wiki.postgresql.org/wiki/SQL_MERGE

"REPLACE INTO" is NOT insert/update. it is insert and delete if there's a duplicate.
http://dev.mysql.com/doc/refman/5.6/en/replace.html

If you want insert/update on mysql you use this: http://dev.mysql.com/doc/refman/5.6/en/insert-on-duplicate.html

There is a difference between updating if there's a duplicate and deleting and inserting if there's a duplicate. The differences might cause pain :).

The Postgresql bunch appear to be working on implementing MERGE instead:
http://wiki.postgresql.org/wiki/SQL_MERGE

Not really sure about the difference in functionality but mysql has geospatial stuff too. Never had a reason to eevn try it out, though--I just remember skimming this section in a reference manual.

The default engine does not even support transactions.

Wrong.

The default storage engine in 5.5.5 and later is InnoDB, which handles both transactions and foreign keys very nicely.

Thanks for playing, though.

Google also uses MySQL for a lot of things. See http://www.mysql.com/customers/view/?id=555

"Google runs critical business systems with MySQL and InnoDB. The systems require 24x7 operation with minimal downtime. The systems support large OLTP and reporting workloads. We are very happy with the scalability, reliability and manageability of this software."

Google and Facebook have worked on many patches and tools for MySQL, and along with work from Percona, MySQL has come a long way as an extremely fast and scalable server in the last few years.

Academic purist discovers that one of the most prolific and successful database users in the world is using a system he doesn't approve of. He decides, with no insider knowledge at all, and despite all evidence to the contrary, that they should throw everything away and start over from scratch using a system that he thinks would allow them to see the performance and scalability that they've already achieved.

Presumably he's tired of Facebook being used as a counter-example to everything he's been preaching.

He's no academic purist. He's pushing his product, and he's either an outright liar or, worse, doesn't know what he's talking about:

Stonebraker said the problem with MySQL and other SQL databases is that they consume too many resources for overhead tasks (e.g., maintaining ACID compliance and handling multithreading)

Is that so? MySQL, as with virtually all SQL DBMSs, defaults to "repeatable read" transactional guarantees, and it doesn't even spend time guaranteeing foreign key relationships by default. About the only thing MySQL really guarantees out of the box is durability.

It's just nonsense to talk about all the "wasted resources" when, if they don't need them, it's a few lines in a config file to turn them off.

Academic purist discovers that one of the most prolific and successful database users in the world is using a system he doesn't approve of. He decides, with no insider knowledge at all, and despite all evidence to the contrary, that they should throw everything away and start over from scratch using a system that he thinks would allow them to see the performance and scalability that they've already achieved.

Presumably he's tired of Facebook being used as a counter-example to everything he's been preaching.

He's no academic purist. He's pushing his product, and he's either an outright liar or, worse, doesn't know what he's talking about:

Stonebraker said the problem with MySQL and other SQL databases is that they consume too many resources for overhead tasks (e.g., maintaining ACID compliance and handling multithreading)

Is that so? MySQL, as with virtually all SQL DBMSs, defaults to "repeatable read" transactional guarantees, and it doesn't even spend time guaranteeing foreign key relationships by default. About the only thing MySQL really guarantees out of the box is durability.

It's just nonsense to talk about all the "wasted resources" when, if they don't need them, it's a few lines in a config file to turn them off.

Have a setting in the tools that call it to use the legacy/broken implementation, and enable it by default in the next patch. See: MySQL old passwords. Or some sort of option that you can set on the function, similar idea.

The better but less compatible way is to put a huge warning on the patch, telling people that if the password doesn't match, check again with the USE_BROKEN_BLOWFISH_IMPLEMENTATION flag passed into the function and if that matches, update your data with the good hash and continue on as normal. That will inevitably piss off a lot of people on shared hosting and/or unmaintained applications but from a security standpoint it's the better option.

My favourite problem was not being able to use variables for the LIMIT clause Bug #11918. Took 5 years to remedy.