Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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.

    • 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   

      • 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 (http://martynov.org/ [martynov.org])

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

          Ilya Martynov (http://martynov.org/ [martynov.org])

          • by lbr (5199) on 2007.09.04 5:39 (#57409)
            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 half table scans.