
MySQL 8.0 is now generally available - theodorejb
https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally-available/
======
tzs
I had hoped that the SQL improvements would fix this annoyance, but according
to the documentation they did not:

    
    
      create table fib ( a integer, b integer );
      insert into fib (a, b) values (1, 0);
      update fib set a=a+b, b=a;
      update fib set a=a+b, b=a;
      update fib set a=a+b, b=a;
      update fib set a=a+b, b=a;
      update fib set a=a+b, b=a;
      select a, b from fib;
    

The correct result according to the SQL standard is a == 8 and b == 5. In
MySQL the result is a == 16 and b == 16. They do document this in the manual,
saying UPDATE evaluates the assignments left to write, and note that this
deviates from the standard.

MariaDB is the same prior to 10.3.5. Starting with 10.3.5 it defaults to left
to write evaluation, but you can set the SIMULTANEOUS_ASSIGNMENT mode flag to
make UPDATE evaluate the assignments simultaneously instead of left to right.

I believe that all other common SQL databases (Sqlite, PostgreSQL, Oracle,
Microsoft SQL Server) follow the standard.

~~~
kbsletten
I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch
this with a 10 ft pole because it's not likely to really affect somebody's
opinion of MySQL enough to switch, but there's going to be at least one person
whose code you'll break. Before you can consider SQL compatibility, you have
to keep most-popular-version-of-mysql compatibility.

~~~
kbenson
I agree. If it's desired, use a config setting to make it the default. It was
already standard practice in any MySQL database I rolled out to set InnoDB as
the default storage engine in the config until it became the shipped default.
Like transaction isolation levels, this is something you either set as an
administrator for your need, or you let the application setup guide steer you,
or you let the application queries specifically set it, if the application
needs it. Otherwise,you risk causing real data corruption and loss to existing
customers purely for the benefit of being more compliant in your _default
configuration_.

A global and per-session setting is sufficient and more beneficial, IMO, so I
think MariaDB took the right approach. If MySQL still doesn't have that
setting, well, that's troubling, but I can't say I'm entirely surprised.

~~~
morgo
MariaDB and MySQL have different goals here - MariaDB wants to offer drop-in
compatibility for Oracle. MySQL has a core-audience of OLTP apps, that are
mostly developed for it specifically.

When designing features, I think it's important to make sure they can benefit
the highest number of users possible. For this one, I don't think it can ever
be the default because of the burden of backward compatibility. So it is
difficult to justify developing it.

------
dankohn1
I think it's disappointing that MySQL is developed in private and then only
pushed to GitHub when released.

I had noticed that it had not been updated in 3 months:

MySQL in the Cloud Native Interactive Landscape
[https://landscape.cncf.io/grouping=landscape&landscape=datab...](https://landscape.cncf.io/grouping=landscape&landscape=database-
and-data-warehouse&selected=my-sql)

Diff showing last commit
[https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...](https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3b2e26aa4337a12eceebb3#diff-
ea4f83e4d8108e8fdb17ec90794f9bdf)

~~~
rogerdpack
At least it's released at all, but yeah, not a community collab :|

------
talawahdotnet
One of the most interesting new features to me is full support of MySQL 8.0 as
a JSON based document store using the new DevAPI[1].

There is a separate blog post highlighting it:
[https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-
the-m...](https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-mysql-
document-store/)

1\. [https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-
users...](https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users-
introduction.html)

------
dancek
There are some very useful features there, but I can't help but think that
MySQL should have had them a long time ago.

Is there something MariaDB doesn't have? I'm genuinely curious as I've only
really followed PostgreSQL development.

~~~
ayan
I feel the same way. I've been using and tracking both since the mid to late
90s.

I've always wondering why, in a world where PostgreSQL exists, would anyone
use MySQL. New releases seems to only slightly close the gap between it and
better RDBMSs while retaining quite a few kludges and ambiguities.

In the meantime PostgreSQL gets better at the same pace.

~~~
evanelias
MySQL is still a perfectly reasonable choice for massive-scale OLTP workloads.
In my mind, a few things MySQL excels at:

* Threaded connection model. Postgres still uses process-per-conn right? This is very painful in situations with high connection churn / fire-and-forget db conns, which are required in some circumstances (heavily sharded environments where keeping persistent connection pools between all app servers and db servers is not practical)

* Ecosystem and experienced talent pool. Among companies with the largest database fleets, a plurality (maybe even a majority) use MySQL, or at least started out on MySQL. This translates to a greater availability of engineers worldwide with experience using and automating giant sharded MySQL fleets, more exposure to MySQL's edge cases, more familiarity with very specific performance characteristics and tuning, etc.

* MySQL's pluggable storage engine API allows flexibility for interesting future possibilities. Facebook migrated part of their MySQL fleet's storage engine from InnoDB (btree-based) to MyRocks (LSM-based) and achieved incredible compression benefits as a result, which translates to huge cost savings, while still being much easier than moving to another DBMS altogether. And AFAIK Postgres does not have comparable compression levels to MyRocks at this time.

* Replication options. I'm sure Postgres will catch up here, but its logical replication support is still relatively new, whereas MySQL has always used logical replication and supports a lot of different topologies and configurations. (Although, I won't cite master-master support as many folks do... it is not a good setup in MySQL and has long been discouraged in the community.)

* InnoDB's use of a clustered index for primary key means that it performs better than a non-clustered storage solution for some (many?) workloads.

Don't get me wrong, Postgres is a wonderful database and absolutely has many
qualities and features that MySQL lacks. But it's not the black-and-white
situation that some make it out to be.

~~~
sjwright
And don't forget the TokuDB storage engine. It has some very interesting and
different scaling/performance characteristics which can provide dramatic
improvements for some workloads.

(Even though TokuDB is probably not the "best" choice for my workload, I love
it for my text-heavy tables because its performance is still great and its on-
disk compression ratios are superb.)

~~~
evanelias
Fair enough, but personally I would be very hesitant to adopt TokuDB for a new
use-case in 2018. Its rate of development and adoption have both slowed
considerably in recent years, and MyRocks covers similar use-cases.

------
semiquaver
> Reliability: DDL statements have become atomic and crash safe, meta-data is
> stored in a single, transactional data dictionary. Powered by InnoDB!

To clarify, does this mean that DDL is now fully transactional the way it is
in postgres?

~~~
theptip
This would be great if so, but it doesn't look like it:

[https://dev.mysql.com/doc/refman/8.0/en/atomic-
ddl.html](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html)

> DDL statements, atomic or otherwise, implicitly end any transaction that is
> active in the current session, as if you had done a COMMIT before executing
> the statement. This means that DDL statements cannot be performed within
> another transaction, within transaction control statements such as START
> TRANSACTION ... COMMIT, or combined with other statements within the same
> transaction.

Sounds like it just means that single ALTER/ADD/REMOVE statements now cannot
fail in an intermediate state, but a sequence cannot be run in a transaction,
so there's still a manual process to unpick a migration that failed half-way
through. (That's always fun in production...)

Perhaps the groundwork has been laid though, and it'll be possible in 9.0.

~~~
deathanatos
> _DDL statements, atomic or otherwise, implicitly end any transaction that is
> active in the current session, as if you had done a COMMIT before executing
> the statement._

That sounds horrifying. Implicitly committing transactions could very well
leave the database in an undefined / inconsistent state, no? That is, from the
applications view, if I do:

    
    
       BEGIN;
         STATEMENT A;
         STATEMENT B;
       END;
    

I would expect either both or neither to succeed, but that paragraph would
suggest that A could succeed, and the transaction be committed. (And who knows
after that?)

Am I missing something?

~~~
marcosdumay
> That sounds horrifying.

That means any previous version could fail during DDL execution and leave your
_metadata_ in an inconsistent state that you couldn't recover.

Now MySQL is about as good as any commercial database.

------
crazygringo
Side question, but why the jump from 5.7 to 8.0?

What happened to 6.0 and 7.0?

Edit: found a kind of answer, though I never heard of 6 and 7 being "used"
before. [1]

> _Why did MySQL version numbering skip versions 6 and 7 and go straight to
> 8.0?_

> _Due to the many new and important features we were introducing in this
> MySQL version, we decided to start a fresh new series. As the series numbers
> 6 and 7 had actually been used before by MySQL, we went to 8.0._

[1] [https://dev.mysql.com/doc/refman/8.0/en/faqs-
general.html#fa...](https://dev.mysql.com/doc/refman/8.0/en/faqs-
general.html#faq-mysql-why-8.0)

~~~
johannes1234321
MySQL 6 was used some 10+ years ago and has seen some alphas. Over time most
things in there have been backported into the 5 series and some ideas for 6.0
didn't work out (i.e. Falcon storage engine) and were stopped. When/how 7 was
used I'm not sure, but jumping from 5.7 to 8 simply drops the first digit,
which was meaningless for a while already. (jumps from 5.5 to 5.6 and 5.6 to
5.7 were huge as well)

~~~
geirhoydalsvik
7 is used for MySQL Cluster, see also
[https://mysqlrelease.com/2018/03/mysql-8-0-it-goes-
to-11/](https://mysqlrelease.com/2018/03/mysql-8-0-it-goes-to-11/) Geir

------
douglasfshearer
> MySQL 8.0 delivers SQL window functions.

Great to see these in a MySQL release. Something so worth having I once had a
script which would automate MySQL -> Postgres for data analytics purposes.

------
pmuk
Does anyone have any idea when this will be available on Amazon RDS?

~~~
riku_iki
Default comment in such topics )

------
go_prodev
Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server
at work and looking to migrate from postgres to MySQL for my personal ML
projects.

Window functions have been a long time coming and I personally can't wait!

~~~
orf
There are a lot of postgres fans on HN, would you mind giving some more info
on why you want to go from PG to MySQL?

~~~
superice
There are some nice features that MySQL lacks. Personally, the thing I like
best in Postgres is transactional DDL. In MySQL, if halfway through a database
transformation your migration script fails, you are in a broken state and you
are on your own. Postgres rolls the whole transaction back. Ofcourse there are
some other features MySQL lacks, such as variable length character columns
(varchar) where you don't need to specify a maximum length.

The transactional DDL seems to be introduced in MySQL per 8.0 though

~~~
madenine
The advantages of Postgres (and MariaDB) over MySQL are pretty well traveled
on HN. OP wants to move from Redshift Postgres & SQL Server to MySQL - which
isn't something you see very often.

------
mdcallag
Release looks great. I can't wait for MyRocks to arrive to make it even
better.

------
ta65377777
I demand satiation.

