> Guess what doesn't fit in 767 bytes? VARCHAR(255) in UTF8MB4. Anything above VARCHAR(191) would not be indexable.
The utf8mb3 optimization was made before InnoDB was the default storage engine (2010).
748 karma · joined August 17, 2009
The utf8mb3 optimization was made before InnoDB was the default storage engine (2010).
While the performance differences are historical now, consider the case that because of fixed sized buffers, one query could switch from a temp table in memory to a temp table on disk. The profile of the query has effectively changed.
There is a pathological case which is not common: max length of all 4-byte characters. Indexes are used to enforce features like unique constraints, it's important that everything can fit in the buffer length.
* Use MySQL 8.0 :-)
The utf8[mb4] support in MySQL 8.0 is much better than prior releases. The team worked really hard on eliminating the use cases for utf8mb3 (performance) so that "just use the default of utf8mb4" can work for everyone.
The sorting order for the utf8 collations is not identical to utf8mb4 ones, and so an upgrade would require indexed columns to be rebuilt (remember, indexes are sorted).
I think with hindsight it would have been better to rip the bandaid off. 8.0 took a middle of the road approach by switching the default to utf8mb4.
w.r.t. arbitrary:
The ordering must be deterministic so that indexes can maintain sorted order. It's possible to create a custom collation to have your own ordering - but I would say most users don't do that.
The default for MySQL 8.0 (current GA) is utf8mb4. I also recommend reading this introduction post here: http://mysqlserverteam.com/sushi-beer-an-introduction-of-utf...
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.
To give a similar example, that I did look at: MySQL can enable more standards equivalent identifier quoting (via an SQL mode): https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmod...
To enable that by default would break a lot of applications.
I wish we could be more civil and not resort to petty insults. Is there anything I wrote you can dispute with a source?
I've been to a Monty talk about this subject, and let me say it was interesting...
Monty starts by saying that he does not acknowledge MySQL 5.6's existence since some new features are an abomination (usually citing GTIDs).
He then compares MySQL 5.5 to MariaDB (of which MariaDB is based on MySQL 5.5; so it contains the superset of features).
MySQL 5.5 was released in 2010. Support for it will end at the end of this year.
Development has diverged a lot since 2010. For a more balanced comparison, I recommend this one: https://www.percona.com/blog/2017/11/02/mysql-vs-mariadb-rea...
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-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.
I don't want to undersell it though: some single operations require multiple steps (i.e. DROP SCHEMA in 5.7 needs to unravel all the tables it discovered and making sure a replica slave produces the same result. 8.0+ does this much cleaner). So it still remains important to have.
w.r.t. tx_isolation:
In MySQL 8.0, it is called transaction_isolation which is the name used by configuration files. MySQL 5.7 supports both names, but now warns when using the old name.
Supporting old+new names is required to support distributed apps which may upgrade a shard at a time (i.e. you want your code to work on both MySQL 5.7 and 8.0). But there is a deprecation warning to let you know which version is preferred.
Calling it an incompatible change is perhaps a little strong. The idea behind the deprecation warning is to give you as much notice as possible.
Fake reviews/astroturfing comments can hurt a brand quite severely. The riskiest situation of course is talking about a competitor's product (which we kind of are here).
It doesn't have to sound like a legal disclaimer, but its nice to identify your relationship to the product may have (even subconscious) bias.
Consider SQL; it's declarative and highly expressive. Your users can craft queries that you did not consider, and you have to make sure they work consistently between versions. It's a very hard problem.
Creating more public APIs? It's a hard sell that vendors are sensitive to. Reducing the surface area makes it easier to add future improvements.
Perhaps the title is click bait, but at the time I was meeting with a lot of users looking for someone else's problems.
5TB could still easily be single server territory. It depends more on the queries.
My point is just that some workloads are better solved with (some) vertical scaling first.
It is a ~$300 test too.
(The internals manual was out of date in many cases. I do not recommend relying on the links mentioned here.)
We're working on moving the internals documentation into the server code with Doxygen: http://mysqlserverteam.com/mysql-8-0-now-documented-with-dox...
https://dev.mysql.com/doc/refman/5.7/en/index-merge-optimiza...
http://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-ove...
http://mysqlserverteam.com/sushi-beer-an-introduction-of-utf... (Problem #1)
(Author is the first link here.)