Home/ Questions/Q 7844817
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T17:00:57+00:00

I have this query, which was working fine. SELECT SUM(amount) FROM company.invoice_line WHERE item_id

  • 0

I have this query, which was working fine.

SELECT SUM(amount) FROM company.invoice_line WHERE item_id != shipping 
    AND item_id != '' 
    AND invoice_id IN 
        (SELECT id_invoices FROM company.invoices WHERE customer = 'XX' 
            AND sales_rep = 'XXX');

The purpose is to sum up all the rep’s sales from a customer. The customer and rep data are related and stored in the invoice table, and the invoice line table related to the invoice table.

For the data sizes I am working with, the query takes about 0.015s

I changed the id_invoices in the query with another PK that was a VARCHAR, but not flagged unique or what not.

The reason was before hand, I had an atrocious design where an invoice would be inserted into the DB, then a query would immediately follow asking the invoice‘s auto-incremented PK for use as a foreign key.

To use BULK INSERT effectively, I needed access to unique identifiers for practically all my data without depending on an auto-incremented, ‘vanilla’ INT PK. I accomplished this by doing as I said above, and adding additional columns that would serve as foreign keys, etc.

My insert rate is now fantastic, but now the query takes 7+ seconds.

To reiterate, before hand I was using vanilla auto-increment int as a PK. Does switching foreign keys to VARCHARs really destroy performance that much?

My next move appears to be reverting to the int id’s, but instead of allowing MySQL to auto-increment on insert, to manually create these int indexes before hand so I can still use bulk insert. From the perspective of the query, it shouldn’t matter… should it?

Any help would be appreciated.

Dane

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Okay, firstly you need to use EXPLAIN to determine what’s happening in the query plan to see what else may have changed.

    Secondly, VARCHAR columns are slower to match than INT columns, though generally it’s just a constant increase (eg it’s k*O(n) vs O(n) where k is not related to n). ….EXCEPT if the character sets are different on the two tables. Then it becomes a huge problem as MySQL tries to match two different character sets. Who knows why, it’s just slow mmkay.

    Thirdly, were your inserts really that slow as to require this massive redesign? It’s not clear from your question what you’re doing, but it’s hard to see how the performance on random inserts was that big a hit on your workload that you needed to make a very nonstandard table structure which makes everything else harder and slower to work around it?

    Finally, your last question about bulk inserts – if you precreate the rows, insert isn’t going to work (unless you do something with ON DUPLICATE KEY). But I’d always try and stick to int IDs for this sort of thing unless there’s a very good reason not to.

    • 0