Sql-server – Worse performance on a new server

What I'd do

• 4 disks for RAID 10 for all log files
• Disk RAID 5 for all data files + OS
• Don't bother with RAM disks

Why?:

• With 24GB RAM all databases will be in memory so RAID 5 doesn't matter because disk reads won't really happen
• Write performance is determined by log file throughput
• Data files are larger then log files so RAID 5 is more efficient

What isn't ideal:

• Not having one volume per database log file
• Separation of local backup drives
• Not having separate RAID 1 for OS + binaries

Other options:

• Define "heavy write": you could go to RAID 1 for LDFs and another for OS for less than a few million rows per day

First, each time you UPDATE the status column, you are having to update the index as well (source). Evaluate your indexing to see if you really need the index on the status column. My guess is no, since it has an extremely low cardinality and MySQL probably won't use it anyway.

If you ignore me and think you do need it, follow the advice in the article to drop the index before your loop and re-add it after you're done.

Here are some other things you might do if that doesn't help:

• You are taking all the columns from the data but only using number. Don't do a SELECT *, but instead a SELECT number. That won't help your writes, but it is a good performance practice. Only select the columns you're using.

• Your number index isn't getting used at all. This means it is not unique enough to be useful for updating. (Slight tangent: how many rows does a single UPDATE affect?) I would drop it, or at least add it to process index.

• It looks like process is unique enough for MySQL to whittle the amount of rows down to 16k, instead of 1 million. In light of this, I would add AND process=x to your update statement (I'm assuming you know process from the original SELECT statement):

  -- FAILED--
  UPDATE data SET status = 2, error='$error' WHERE process=X AND number = $data['number']
  
  -- SUCCESS --
  UPDATE data SET status = 1 WHERE process=X AND number = $data['number']
  

A hint about unnecessary indexes in InnoDB. InnoDB is using a hidden 'primary key' (since you don't have one defined) and is using that when it writes the indexes. So for each Index you're using, you add the size of the index + the size of the hidden primary key to the data file. If you're not using the index (or MySQL can't use it), you are wasting space and adding overhead each time you insert a new number (same for status, as discussed earlier)