3 ms·
> The main effort of the team has been focused on speed, with performance reportedly improved from 2 to 3 times compared to previous releases. Definitely good
by jkoudys 12y ago
> The main effort of the team has been focused on speed, with performance reportedly improved from 2 to 3 times compared to previous releases.
Definitely good news, as MySQL came out during the peak of Moore's-law (or, more appropriately, a misapplication of) fueled idiocy where nobody seemed interested in investing in better performing software, since they all expected they'd have faster hardware next year. Now everybody's deploying to VPSes, so it's once again important that we get the most out of every single CPU cycle. I haven't gone through all the diffs, but if they're promising 2x to 3x improved performance, there must have been some pretty fundamental rewrites of old code.
Coming from the Oracle + DB2 world, what I'd really like to see is some improved performance analysis and query optimization tools. There have been some incremental improvements to EXPLAIN (the new 'EXPLAIN on a named connection' feature seems pretty cool for when I have 10+ application instances all connecting to my DB), but it's still got a long way to go.
- morgo 12y agoI totally hear you here :) Visibility is the most useful and always under-rated feature. If I can clarify some of the recent enhancements here: - MySQL 5.6 introduced `EXPLAIN FORMAT=JSON`. MySQL Workbench uses this to visualize query plans (important as they get complicated.) - Also in 5.6 was optimizer trace (find out why indexes were not used etc.) and performance_schema enabled by default. - MySQL 5.7 adds cost information to `EXPLAIN FORMAT=JSON` (Workbench also understands it.) - Workbench also has a set of performance views based on Performance_schema (based on a project called SYS). You can install it as standalone from here too: https://github.com/MarkLeith/mysql-sys https://github.com/MarkLeith/mysql-sys - The runtime performance data from SYS is very useful for making correct optimization decisions. Being an SQL interface is also friendly for writing your own scripts against it. Also, to clarify on your first paragraph: Yes, refactoring old code was one of the ways this was achieved. We picked refactoring targets based on performance and because some of the older code is not very testable.