Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • How fast is

    SELECT authname FROM invoices i WHERE i.affid = 654248 AND i.commpaid = 0;

    You're doing a full table scan on invoices alone, without the join, and that SHOULD be painful.

    So, index on affid.

    • by Ovid (2709) on 2007.09.04 4:43 (#57400) Homepage Journal

      Bingo! That reduces the query time down to .15 seconds :)

      I don't understand the EXPLAIN output as well as I should (duh!). How did you deduce the full table scan on invoice from this?

      +----+-------------+-------+--------+------------------+----------+---------+--- -------------+---------+-------------+
      | id | select_type | table | type   | possible_keys    | key      | key_len | ref            | rows    | Extra       |
      +----+-------------+-------+--------+------------------+----------+--------- +----------------+---------+-------------+
      |  1 | SIMPLE      | b     | ref    | desctype,invoice | desctype | 4       | const          | 1879054 |             |
      |  1 | SIMPLE      | i     | eq_ref | PRIMARY          | PRIMARY  | 4       | data.b.invoice |       1 | Using where |
      +----+-------------+-------+--------+------------------+----------+---------+ ----------------+---------+-------------+

      The reason I thought it was pretty much a problem on the bill table is because I have almost 2 million records with a desctype of zero and I figured MySQL was scanning those linearly.

      • Don't look at me, I try to avoid mysql :-)
      • Well, it is not really a full table scan but it is close to this. Explain select says that it needs to scan 1879054 rows out of 3770990. Concerning performance it is pretty much equivalent to the full table scan. Actually if lookup on an index returns ~50% or more of your table it could be even slower that the full table scan.

        Ilya Martynov ( [])

        • Oh, I forgot to add. It is a full table scan on table 'bill', no on table 'invoice'.

          Ilya Martynov ( [])

          • Without knowing anything about mysqls optimizer, that's easy enough to understand.

            With the original setup, there was a key (and therefore likely an index) on b.desctype, limiting the need for a full tablescan on bills down to "just" half the table. Which turns out to be slightly less work than a full table scan on invoices. So now it has a (long) list of invoice id's it can use the primary key index on invoices to find.

            Adding the index on affid, makes it a LOT cheaper to use that than either the full or

        • Um, your 50% figure is off slightly.

          By about an order of magnitude.

          The actual figure is highly hardware dependent, but should generally be in the range 5-10%.