12 ms·

MySQL 8.0 is now generally available

221 points by theodorejb 8y ago

dancek 8y ago
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.
- go_prodev 8y ago
  No, at this point Maria has surpassed MySQL, however over time we'll likely see the two diverge as MySQL creates new storage types and heads in a different strategic direction.
- meritt 8y ago
  The big features that MySQL has been lacking, MariaDB has had since at least 10.2 (Apr 2016) or earlier. Specifically I'm talking about Windowing functions, CTEs, JSON support, GIS support, Metadata in transactions (DDL statements). At this point MySQL is playing catch-up to MariaDB.
  - morgo 8y ago
    Former MySQL Product Manager here (no longer affiliated). To cover your specifics: MySQL was first in offering JSON with 5.7. It is still well ahead, for example, there is no JSON_TABLE, aggregate functions, native type or partial update in MariaDB. Some examples of the value here: https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-json-documents-and-back-again/ https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-jso... Both have always had GIS support, but have taken it in a different direction. With MySQL, the GIS is now based on Boost.Geometry and has Geography support. w.r.t. metadata in transactions - I am not sure which feature you refer to here. The native innodb-based dictionary is a MySQL only feature. For Window functions and CTEs, they were added at a similar time, but MySQL is on a ~3yr release cycle. MariaDB is on a ~1yr.
    - meritt 8y ago
      > I am not sure which feature you refer to here The same complaint that every single person brings up about MySQL when being compared to Postgres, including in this thread: DDL changes made during transactions cannot be rolled back.
      - morgo 8y ago
        MariaDB does not have that feature: https://mariadb.atlassian.net/browse/MDEV-4259 https://mariadb.atlassian.net/browse/MDEV-4259
    - willvarfar 8y ago
      Mariadb has JSON it just doesn't call it that - it's terminology is dynamic columns. Source: have code that works on both.
      - morgo 8y ago
        It has both (now). It's a stretch to say Dynamic columns are on the same level. For example, could you index them with virtual generated columns? The syntax is also not as transparent to applications as the ->> JSON operator.
        willvarfar 8y ago
        Oracle owns the JavaScript trademark and has started enforcing it. Kinda wise in hindsight that Mariadb didn't call it json? I think Mariadb was there first. I think the format is very similar at the bit level, but the MySQL has nicer API with automatic returning it as text to apps rather than exposing the bits. I dislike json_extract and wish >> worked but it doesn't seem to on my percona server :( Anyhow, you'll look back when you've got more distance from Oracle and realize that you don't need to try and convince yourself that MySQL was better quite so hard ;)
        morgo 8y ago
        JSON is part of the SQL 2016 standard and exists in other databases as well. I don't see how the trademark is relevant here. I wish we could be more civil and not resort to petty insults. Is there anything I wrote you can dispute with a source?
- cdevnull 8y ago
  The main reason I don't use mariaDb is the non support of nullable spatial index. https://mariadb.com/kb/en/library/spatial-index/ https://mariadb.com/kb/en/library/spatial-index/
- ayan 8y ago
  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.
  - gaius 8y ago
    I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL I am a solid Postgres guy, but MySQL still has a better multi-master replication story. Confident that Postgres will eventually surpass it, possibly even in a later iteration of 10. Now in a world where Postgres exists why would anyone use MongoDB is a valid question...
    - ptman 8y ago
      Postgres 11? Postgres 10 will only get bug fixes. The version numbering was changed with 10
  - greenhouse_gas 8y ago
    1. LAMP - If you're working with shared hosting, there isn't much of a choice. 2. WordPress. 3. If you need something simple and basic, MySQL is much easier to get up and running.
    - nik736 8y ago
      I agree with 1 and 2 but I don't understand 3. Can you please elaborate?
      - lstamour 8y ago
        Biggest difference for me is that MySQL always pushed a simpler user structure while most *nix Postgres packages prefer having corresponding native OS users by default (PAM vs password auth). Also, it always seemed easier to migrate/upgrade MySQL data folders compared to Postgres ones. The specifics aren’t coming to mind right now, though. Finally I know way too many folks who prefer phpMyAdmin, especially when provided from their cheap shared hosting provider. Don’t get me wrong, I prefer Postgres generally too, but I can definitely see wins to MySQL on ease-of-use. Especially the less standard but more forgiving SQL syntax and simple DESCRIBE commands. Yes the quirks add up for MySQL but Postgres has its share of quirks too.
- petre 8y ago
  > Is there something MariaDB doesn't have? * Proper native JSON support * Spatial support lags behind MySQL However we are still using it in production and MySQL 8 is a no go given that it removed MyISAM support. We still use MyISAM due to fast inserts and easy backup (just copy the files). We use MariaDB for storing IoT time series data.
  - sjwright 8y ago
    Have you explored the TokuDB storage engine? Or Aria?
    - petre 8y ago
      Yes. Aria is one of the reasons we are using MariaDB in fact. It offers a great migration path from MyISAM. We migrated from MySQL 4.6, that's why our tables are in fact MyISAM. We currently have a test server running using Aria tables. I have also thought about using TokuDB but SuSE (13.2) didn't ship a module for it then. I have to check again in 42.3. The only real issues with MariaDB is lack of proper JSON and spatial support which would be of great use to us. I'm talking about a real JSON data type with validation and means to query and maybe even replace JSON, not a mere alias for the LONGTEXT data type. We intend to switch to Postgres on the long run. It has everything we want, moreso with TimescaleDB extensions which could proove very useful for storing time series data. We are currently using it for the spatial database.
go_prodev 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
    - semiquaver 8y ago
      > The transactional DDL seems to be introduced in MySQL per 8.0 though I thought so as well from the release note wording, thanks to theptip for confirming in the docs that DDL is not transactional in 8.0, just crash-safe. see https://news.ycombinator.com/item?id=16876549 https://news.ycombinator.com/item?id=16876549.
  - cdevnull 8y ago
    I did a project with postgres and symfony+doctrine. At 80% of completion, I moved to mySql because I needed spatial index, I installed Postgis but got a lot of problems with doctrine-migration.
semiquaver 8y ago
> 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 8y ago
  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.
  - geirhoydalsvik 8y ago
    This is correct. DDLs are (still) auto committed, but they now cannot fail in an intermediate state. Discussing full transactional DDL should also take into account DDL being Replicated and on Online Schema changes (perhaps more important for Web-scale). Then it starts to become complicated supporting full transactional DDL (at the same time). But transactional DDL is absolutely a desired feature. Geir
  - deathanatos 8y ago
    > 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?
crazygringo 8y ago
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#faq-mysql-why-8.0 https://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#fa...
- giancarlostoro 8y ago
  People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.
  - genieyclo 8y ago
    Oracle 18...
  - dpcx 8y ago
    "start to think" ? Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.
    - greenhouse_gas 8y ago
      You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)
      - collinmanderson 8y ago
        FYI, There always have been actual version numbers under the hood. They kind of messed up 7's number. I guess they had so much trouble changing things from 5.1 to 6.0, they decided another major version bump would be problematic. They apparently changed their minds with 10. 3.10 - 3.1 4.00 - 95 4.10 - 98 4.90 - ME NT 5.0 - 2000 NT 5.1 - XP NT 6.0 - Vista NT 6.1 - 7 NT 6.2 - 8 NT 10.0 - 10 https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...
talawahdotnet 8y ago
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-mysql-document-store/ https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-m... 1. https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users-introduction.html https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users...
falanjito 8y ago
MySQL is a great database for PHP developers. In other words, a piece of SHIT.
dankohn1 8y ago
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=database-and-data-warehouse&selected=my-sql https://landscape.cncf.io/grouping=landscape&landscape=datab... Diff showing last commit https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3b2e26aa4337a12eceebb3#diff-ea4f83e4d8108e8fdb17ec90794f9bdf https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...
- rogerdpack 8y ago
  At least it's released at all, but yeah, not a community collab :|
douglasfshearer 8y ago
> 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.
deleted 8y ago
[deleted]
ta65377777 8y ago
I demand satiation.
pmuk 8y ago
Does anyone have any idea when this will be available on Amazon RDS?
- riku_iki 8y ago
  Default comment in such topics )
tzs 8y ago
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 8y ago
  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.
  - iteriteratedone 8y ago
    No .... this is perfect for a config flag ... you can make it table specific. Then 4 versions later ... this flag is default 1 more version ... we are now standard compliant
  - kbenson 8y ago
    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.
mdcallag 8y ago
Release looks great. I can't wait for MyRocks to arrive to make it even better.

221 points by theodorejb 8y ago

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.

go_prodev 8y ago
No, at this point Maria has surpassed MySQL, however over time we'll likely see the two diverge as MySQL creates new storage types and heads in a different strategic direction.
meritt 8y ago
The big features that MySQL has been lacking, MariaDB has had since at least 10.2 (Apr 2016) or earlier. Specifically I'm talking about Windowing functions, CTEs, JSON support, GIS support, Metadata in transactions (DDL statements). At this point MySQL is playing catch-up to MariaDB.
- morgo 8y ago
  Former MySQL Product Manager here (no longer affiliated). To cover your specifics: MySQL was first in offering JSON with 5.7. It is still well ahead, for example, there is no JSON_TABLE, aggregate functions, native type or partial update in MariaDB. Some examples of the value here: https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-json-documents-and-back-again/ https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-jso... Both have always had GIS support, but have taken it in a different direction. With MySQL, the GIS is now based on Boost.Geometry and has Geography support. w.r.t. metadata in transactions - I am not sure which feature you refer to here. The native innodb-based dictionary is a MySQL only feature. For Window functions and CTEs, they were added at a similar time, but MySQL is on a ~3yr release cycle. MariaDB is on a ~1yr.
  - meritt 8y ago
    > I am not sure which feature you refer to here The same complaint that every single person brings up about MySQL when being compared to Postgres, including in this thread: DDL changes made during transactions cannot be rolled back.
    - morgo 8y ago
      MariaDB does not have that feature: https://mariadb.atlassian.net/browse/MDEV-4259 https://mariadb.atlassian.net/browse/MDEV-4259
  - willvarfar 8y ago
    Mariadb has JSON it just doesn't call it that - it's terminology is dynamic columns. Source: have code that works on both.
    - morgo 8y ago
      It has both (now). It's a stretch to say Dynamic columns are on the same level. For example, could you index them with virtual generated columns? The syntax is also not as transparent to applications as the ->> JSON operator.
      - willvarfar 8y ago
        Oracle owns the JavaScript trademark and has started enforcing it. Kinda wise in hindsight that Mariadb didn't call it json? I think Mariadb was there first. I think the format is very similar at the bit level, but the MySQL has nicer API with automatic returning it as text to apps rather than exposing the bits. I dislike json_extract and wish >> worked but it doesn't seem to on my percona server :( Anyhow, you'll look back when you've got more distance from Oracle and realize that you don't need to try and convince yourself that MySQL was better quite so hard ;)
        morgo 8y ago
        JSON is part of the SQL 2016 standard and exists in other databases as well. I don't see how the trademark is relevant here. I wish we could be more civil and not resort to petty insults. Is there anything I wrote you can dispute with a source?
cdevnull 8y ago
The main reason I don't use mariaDb is the non support of nullable spatial index. https://mariadb.com/kb/en/library/spatial-index/ https://mariadb.com/kb/en/library/spatial-index/
ayan 8y ago
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.
- gaius 8y ago
  I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL I am a solid Postgres guy, but MySQL still has a better multi-master replication story. Confident that Postgres will eventually surpass it, possibly even in a later iteration of 10. Now in a world where Postgres exists why would anyone use MongoDB is a valid question...
  - ptman 8y ago
    Postgres 11? Postgres 10 will only get bug fixes. The version numbering was changed with 10
- greenhouse_gas 8y ago
  1. LAMP - If you're working with shared hosting, there isn't much of a choice. 2. WordPress. 3. If you need something simple and basic, MySQL is much easier to get up and running.
  - nik736 8y ago
    I agree with 1 and 2 but I don't understand 3. Can you please elaborate?
    - lstamour 8y ago
      Biggest difference for me is that MySQL always pushed a simpler user structure while most *nix Postgres packages prefer having corresponding native OS users by default (PAM vs password auth). Also, it always seemed easier to migrate/upgrade MySQL data folders compared to Postgres ones. The specifics aren’t coming to mind right now, though. Finally I know way too many folks who prefer phpMyAdmin, especially when provided from their cheap shared hosting provider. Don’t get me wrong, I prefer Postgres generally too, but I can definitely see wins to MySQL on ease-of-use. Especially the less standard but more forgiving SQL syntax and simple DESCRIBE commands. Yes the quirks add up for MySQL but Postgres has its share of quirks too.
petre 8y ago
> Is there something MariaDB doesn't have? * Proper native JSON support * Spatial support lags behind MySQL However we are still using it in production and MySQL 8 is a no go given that it removed MyISAM support. We still use MyISAM due to fast inserts and easy backup (just copy the files). We use MariaDB for storing IoT time series data.
- sjwright 8y ago
  Have you explored the TokuDB storage engine? Or Aria?
  - petre 8y ago
    Yes. Aria is one of the reasons we are using MariaDB in fact. It offers a great migration path from MyISAM. We migrated from MySQL 4.6, that's why our tables are in fact MyISAM. We currently have a test server running using Aria tables. I have also thought about using TokuDB but SuSE (13.2) didn't ship a module for it then. I have to check again in 42.3. The only real issues with MariaDB is lack of proper JSON and spatial support which would be of great use to us. I'm talking about a real JSON data type with validation and means to query and maybe even replace JSON, not a mere alias for the LONGTEXT data type. We intend to switch to Postgres on the long run. It has everything we want, moreso with TimescaleDB extensions which could proove very useful for storing time series data. We are currently using it for the spatial database.

go_prodev 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.
  - semiquaver 8y ago
    > The transactional DDL seems to be introduced in MySQL per 8.0 though I thought so as well from the release note wording, thanks to theptip for confirming in the docs that DDL is not transactional in 8.0, just crash-safe. see https://news.ycombinator.com/item?id=16876549 https://news.ycombinator.com/item?id=16876549.
- cdevnull 8y ago
  I did a project with postgres and symfony+doctrine. At 80% of completion, I moved to mySql because I needed spatial index, I installed Postgis but got a lot of problems with doctrine-migration.

semiquaver 8y ago

> 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 8y ago
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.
- geirhoydalsvik 8y ago
  This is correct. DDLs are (still) auto committed, but they now cannot fail in an intermediate state. Discussing full transactional DDL should also take into account DDL being Replicated and on Online Schema changes (perhaps more important for Web-scale). Then it starts to become complicated supporting full transactional DDL (at the same time). But transactional DDL is absolutely a desired feature. Geir
- deathanatos 8y ago
  > 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?

crazygringo 8y ago

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#faq-mysql-why-8.0 https://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#fa...

giancarlostoro 8y ago
People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.
- genieyclo 8y ago
  Oracle 18...
- dpcx 8y ago
  "start to think" ? Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.
  - greenhouse_gas 8y ago
    You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)
    - collinmanderson 8y ago
      FYI, There always have been actual version numbers under the hood. They kind of messed up 7's number. I guess they had so much trouble changing things from 5.1 to 6.0, they decided another major version bump would be problematic. They apparently changed their minds with 10. 3.10 - 3.1 4.00 - 95 4.10 - 98 4.90 - ME NT 5.0 - 2000 NT 5.1 - XP NT 6.0 - Vista NT 6.1 - 7 NT 6.2 - 8 NT 10.0 - 10 https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...

talawahdotnet 8y ago

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-mysql-document-store/ https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-m... 1. https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users-introduction.html https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users...

falanjito 8y ago

MySQL is a great database for PHP developers. In other words, a piece of SHIT.

dankohn1 8y ago

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=database-and-data-warehouse&selected=my-sql https://landscape.cncf.io/grouping=landscape&landscape=datab... Diff showing last commit https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3b2e26aa4337a12eceebb3#diff-ea4f83e4d8108e8fdb17ec90794f9bdf https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...

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

douglasfshearer 8y ago

> 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.

deleted 8y ago

[deleted]

ta65377777 8y ago

I demand satiation.

pmuk 8y ago

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

riku_iki 8y ago
Default comment in such topics )

tzs 8y ago

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 8y ago
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.
- iteriteratedone 8y ago
  No .... this is perfect for a config flag ... you can make it table specific. Then 4 versions later ... this flag is default 1 more version ... we are now standard compliant
- kbenson 8y ago
  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.

mdcallag 8y ago

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