views:

50

answers:

2

I am inserting about 400 rows into a table at a time (SQL Server 2008). I have tried UNION ALL, but that slowed things down considerably. I settled on the following query:

INSERT INTO table VALUES (a, b,...),(c, d,...),...(x,y,...); 

When I make this query through ODBC it takes roughly 400ms (I use C++ and time the single call to sqlExecDirect going to odbc32.dll). However, when I run the query inside MS SQL Server Management Studio wrapped by Getdate():

SELECT Getdate()
INSERT INTO ...
SELECT Getdate()

it takes ~10ms. For comparison, on the same machine, the same query in MySQL takes roughly 20ms.

  1. Is SELECT Getdata() a reliable way to time a transaction?
  2. Why is MS SQL Server Management Studio so much faster?
  3. What can I do to improve the performance? Any alternatives to ODBC? Direct connect to SQL server?
A: 

The first connection usually takes a while to set up. This can explain an initial delay: in SSMS, the connection will already be in place when you start the query. Try to do the insert twice from the same C++ program and see if that makes a difference.

Also: what ODBC driver are you using? For ODBC, consider the native driver:

Driver={SQL Server Native Client 10.0};Server=myServerAddress;
    Database=myDataBase;Uid=myUsername;Pwd=myPassword;

Instead of ODBC, You could also use ADO through COM. That's quite easy to do with a generated wrapper. Then you can connect using OLE DB:

Provider=SQLNCLI10;Server=myServerAddress;
    Database=myDataBase;Uid=myUsername; Pwd=myPassword;
Andomar
Changing the driver to SQL Server Native Client 10.0 didn't affect performance.It seems that all of the time is spent in "SQL Server parse and compile time", which I assume is an operation that happens on the server. I am not sure what SQL server is doing, but taking 400ms to parse and compile 40kb of text seems way to long.
ihamer
A: 

the way you are benchmarking, you are not capturing compile time. Do this:

SET STATISTICS TIME ON
GO
INSERT INTO ...
AlexKuznetsov