Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to optimize a table for fast inserts only?

I have a log table that will receive inserts from several web apps. I wont be doing any searching/sorting/querying of this data. I will be pulling the data out to another database to run reports. The initial table is strictly for RECEIVING the log messages.

Is there a way to ensure that the web applications don't have to wait on these inserts? For example I know that adding a lot of indexes would slow inserts, so I won't. What else is there? Should I not add a primary key? (Each night the table will be pumped to a reports DB which will have a lot of keys/indexes)

like image 711
Neil N Avatar asked Sep 23 '09 20:09

Neil N


People also ask

How can I speed up my table insert?

To get the best possible performance you should: Remove all triggers and constraints on the table. Remove all indexes, except for those needed by the insert. Ensure your clustered index is such that new records will always be inserted at the end of the table (an identity column will do just fine).

Is bulk insert faster than insert?

In case of BULK INSERT, only extent allocations are logged instead of the actual data being inserted. This will provide much better performance than INSERT. The actual advantage, is to reduce the amount of data being logged in the transaction log.

Why is insert so slow?

3. Inserts are slower against a Heap (no Clustered index) Inserts against a table with no clustered index (heap) are optimized for saving space, rather than performance. This means that SQL Server will spend more time searching for available space than when a clustered index is used.


2 Answers

If performance is key, you may not want to write this data to a database. I think most everything will process a database write as a round-trip, but it sounds like you don't want to wait for the returned confirmation message. Check if, as S. Lott suggests, it might not be faster to just append a row to a simple text file somewhere.

If the database write is faster (or necessary, for security or other business/operational reasons), I would put no indexes on the table--and that includes a primary key. If it won't be used for reads or updates, and if you don't need relational integrity, then you just don't need a PK on this table.

To recommend the obvious: as part of the nightly reports run, clear out the contents of the table. Also, never reset the database file sizes (ye olde shrink database command); after a week or so of regular use, the database files should be as big as they'll ever need to be and you won't have to worry about the file growth performance hit.

like image 91
Philip Kelley Avatar answered Nov 07 '22 20:11

Philip Kelley


Here are a few ideas, note for the last ones to be important you would have extremly high volumns:

  • do not have a primary key, it is enforced via an index
  • do not have any other index
  • Create the database large enough that you do not have any database growth
  • Place the database on it's own disk to avoid contention
  • Avoid software RAID
  • place the database on a mirrored disk, saves the calculating done on RAID 5
like image 39
Shiraz Bhaiji Avatar answered Nov 07 '22 19:11

Shiraz Bhaiji