views:

640

answers:

6

SQL Server (2005/2008)

Each of the below statements have the same result. Does anyone know if one outperforms the other?

insert into SOMETABLE 
  values ('FieldOneValue','FieldTwoValue',3,4.55,'10/10/2008 16:42:00.000')

insert into SOMETABLE 
  select 'FieldOneValue','FieldTwoValue',3,4.55,'10/10/2008 16:42:00.000'

insert into SOMETALBE
  Select
    Field1 = 'FieldOneValue',
    Field2 = 'FieldTwoValue',
    Field3 = 3,
    Field4 = 4.55,
    Field5 = '10/10/2008 16:42:00.000'

Assuming of course that the data types match the table appropriately...

A: 

It looks like you're just mimicking

Insert into SOMETABLE ( SELECT * FROM SOMEOTHERTABLE )

Aaron Smith
+9  A: 

i think, based on this question, you are to the point of premature optimization. i'd stick to the standard insert () values () if you are just inserting 1 record and let the Sql Server team make it the most performant.

Darren Kopp
I agree that this is premature optimization. There are so many other performance issues that are more important. However, if the issue is bulk loading of lots of rows, it's often better to use a vendor-specific feature like MySQL's LOAD DATA INFILE because they perform much better.
Bill Karwin
agree, sql server has a bulk insert command as well.
Darren Kopp
I'm actually not prematurely optimizing. I'm not optimizing at all, I was just curious on a base level about the performance, which appears a negligible difference in all cases.
theo
exactly, which is pre-mature optimization.
Darren Kopp
+2  A: 

I would suspect that if there were a performance difference, it would be in favour of the former, although I doubt there is one.

Nevertheless, this is one of those cases where opting for the clearer version (i.e. with VALUES) provides a readability and maintainability benefit which outweighs the likely negligible performance impact. If you're specifying all the values, then stick to the usual convention, in case someone else reads the code, which at first glance might seem to be doing an INSERT...SELECT from another table, which is a misleading appearance.

Rob
I'm not sure I agree. Let's say I'm doing a Insert from a c# application. This query is going to be used over and over with the values plopped into it. For someone maintaining my code, the verbose third version is probably easier to understand than the Valuse() version.
theo
theo: You're right, of course; the point I was making was, stick to whatever's cleanest, clearest and most readable, which might vary from situation to situation.
Rob
A: 

ignore this comment, its wrong. sorry about that :(

I know you can't use INSERT VALUES() when you're entering more than one row.

INSERT INTO Table SELECT 1, 2, 3, (SELECT 4 FROM Table2 WHERE columnA = columnB)

Miles
Is this true of SQL server? other RDBMS let you do this:INSERT INTO table values ('a1','a2'), ('b1','b2');
Draemon
...MySQL, for example.
Rob
@Miles: Incorrect. Standard SQL, and most implementations, support INSERT with more than one row.
Bill Karwin
my bad, i thought i had the correct syntax when I tried before and I couldn't get it to work... :*(
Miles
+5  A: 

I just tested this.

5 million iterations of both approaches on two sets of hardware, one a server with 16GB RAM, one a notebook with 1GB.

Result: They appear to be the same.

The query plans for these are the same, and the performance differential is statistically insignificant.

Pittsburgh DBA
A: 

For SQL Server, just use this pattern

INSERT INTO TableName (fieldList) SELECT (valueList/columnList) [FROM and so on]

This is the only insert pattern you'll ever need. It does everything. Do specify the fieldlist to protect your statement from future table changes (where optional columns are added).

There are some minor nuances to using INSERT INTO VALUES, which I don't remember because I don't have to.

David B
The syntax of SELECT with no FROM clause is not standard SQL. Several brands do support it, but not all.
Bill Karwin