3 ms·

>came from the old brain-dead MySQL query optimizer (which has since been fixed, as far as I know). It came from the fact that mysql doesn't support joins prop

• zamalek 12y ago
  Yep, choosing the correct joining method is one of the tasks that a query optimizer (a.k.a. join engine) performs. I think someone around here pointed me toward a document that indicated that there was, at the very least, an experimental competent query optimizer in the MySQL codebase. Even then it's a far cry away from "the big guns." Things like statistics, DPVs, etc. simply aren't (edit: or weren't) present in MySQL: which are more examples of a critical components of efficient database design at massive load scales. TLDR; MySQL simply isn't competitive, it's being improved (especially MariaDB) but is a long ways off.
• wvenable 12y ago
  MySQL's optimizer isn't best of breed but your comment is massively ignorant. MySQL supports transactions, row level locking, nested SQL, and even replication -- how would you ever get the idea that it only ever just supported nested loop joins?
  • zamalek 12y ago
    He's referring specifically to the features within the joining engine, not MySQL as a whole. [Edit] I'm refuting that this: > MySQL supports transactions, row level locking, nested SQL, and even replication is relevant in the context of what he said.
    • wvenable 12y ago
      MySQL always did more than nested loop joins -- which is literally the worst kind of join. It's the join you get if you have no indexes on anything in any DBMS. I fail to see what your reply here is trying to refute. Even your comment, stating that MySQL doesn't maintain statistics, it's totally wrong and easily checked with 5 seconds of Googling. To your edit: The idea that a DBMS would support so many advanced features and do nested loop joins is laughably ridiculous.
      • dsp1234 12y ago
        I'm no MySQL expert, but the docs for 5.6 specifically state: "MySQL resolves all joins using a nested-loop join method." [0] Can you provide documentation on other join methods? [0] - http://dev.mysql.com/doc/refman/5.6/en/explain-output.html http://dev.mysql.com/doc/refman/5.6/en/explain-output.html
        • wvenable 12y ago
          MySQL sort-merge joins, it's right in that documentation, but it calls everything out as optimizations on nested-loop. http://www.xaprb.com/blog/2013/10/01/mysql-isnt-limited-to-nested-loop-joins/ http://www.xaprb.com/blog/2013/10/01/mysql-isnt-limited-to-n... It doesn't do hash joins which is the biggest limitation but MySQL is pretty good a joins and certainly was never bad enough to warrant it's reputation. It's toolbox is smaller than other RDBMS products but it's not empty.
          • saosebastiao 12y ago
            You claim that MySQL always did more than nested loop joins, and yet the features cited in that blog post were introduced in version 5.6, which was released in 2013... Several years after the other advanced features that supposedly preclude MySQL from doing something as stupid as nested loop joins.
            • deleted 12y ago
              [deleted]
      • saosebastiao 12y ago
        > The idea that a DBMS would support so many advanced features and do nested loop joins is laughably ridiculous. Correct. MySQL is laughably ridiculous.
  • imanaccount247 12y ago
    No, my comment is a simple statement of fact. None of what you just mentioned is even remotely relevant. I get the idea that it only supports nested loop joins because it only supports nested loop joins. "MySQL resolves all joins using a nested-loop join method": http://dev.mysql.com/doc/refman/5.6/en/explain-output.html http://dev.mysql.com/doc/refman/5.6/en/explain-output.html