5–years old.<p>It’s interesting that the current LTS for MySQL is already 5-years old (2018).<p>I’m surprised there isn’t a more current LTS.<p><a href="https://en.m.wikipedia.org/wiki/MySQL" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/MySQL</a><p>Especially when you see this quoted by MySQL team:<p><pre><code> ‘About every 2 years a new Long Term Support version will be released
</code></pre>
<a href="https://dev.mysql.com/blog-archive/introducing-mysql-innovation-and-long-term-support-lts-versions/" rel="nofollow noreferrer">https://dev.mysql.com/blog-archive/introducing-mysql-innovat...</a>
Does anyone know if the performance regressions between 5.7 and 8.0 have been fixed? I no longer use MySQL regularly so I haven't been following this.<p>If I recall correctly, this was one of the major reasons why people were deferring this upgrade.<p>---<p>> Most notably, we encountered a problem where queries with large WHERE IN clauses would crash MySQL. We had large WHERE IN queries containing over tens of thousands of values.<p>The need to rewrite queries is mildly concerning. If this was part of their Rails codebase, I'm curious if these patches will make it into the ORM.
I figured this would be an opportunity for further vertical integration directly with Azure’s MySQL product.<p>Was there a reason this wasn’t done? The article seems rather explicit of running on top of Azure VMs.
> This is the story of how we seamlessly upgraded our production fleet to MySQL 8.0.<p>Was it seamless? I recall GitHub being down a bunch lately, and even though the downtime is unrelated to the db upgrade, from the outside looking in, I don't know that I'd lean that hard on having done that seamlessly.