Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Which inserts faster, XML field or Varchar(max) field?

We have a history table that stores xml web service requests and responses. Currently it stores them into an XML field, but we're having performance issues with inserts. We only insert records, no updates, selects or deletes. We've truncated the table and rebuilt the index, to no avail. The table has a Primary clustered index on the identity field, and a default value, GetDate(), on a datetime field. We're running SQL 2005 Server, but the database is in SQL 2000 compatibility mode.

If we change the field type from XML to VarChar(max) or VarChar(xxx), would this speed up the inserts? Is there anything else we should be looking at?

Thanks.

like image 290
Jim Avatar asked May 06 '10 15:05

Jim


People also ask

Does VARCHAR Max affect performance?

Yes, it can affect performance, as space needs to be allocated to hold large values in the query engine. In your case, you could also use a suitably large size such as varchar(50) which would easily hold whatever you needed.

Why CHAR is faster than VARCHAR?

Searching is faster in CHAR as all the strings are stored at a specified position from the each other, the system doesnot have to search for the end of string. Whereas in VARCHAR the system has to first find the end of string and then go for searching.

Does VARCHAR max waste space?

Even using varchar(max) shouldn't have any impact on storage. Instead, a goal might be to limit the actual size of each data row to ~8000 bytes if possible.

When should I use nvarchar Max?

Use varchar when the sizes of the column data entries vary considerably. Use varchar(max) when the sizes of the column data entries vary considerably, and the size might exceed 8,000 bytes.


1 Answers

It depends what the performance problem is.

  • If is CPU bound, then the XML validation could be a factor and varchar(max) could be faster.
  • If is IO bound then the XML compressed storage is better than the nvarchar(max) loose format and you'd loose performance.
  • On the other hand, if the problem XML fragments are small the varchar storage presents the opportunity for in-row storage and may bet better than XML
  • On yet another hand the in-row storage would decrease the leaf pages row density and cause performance problems for reads.
  • If the problem is neither CPU nor IO but is lock contention, then the XML vs. varchar issue is orthogonal to the performance problem. Same goes for insert hot spot page latch contention problem. And again, same goes for log flush performance problem. All would manifest as 'slow inserts' (for some definition of slow) and none would change in the slightest by replacing an XML with varchar.

So, as with all performance problems, the recommendation is to measure first and cut later. The recommended approach is to apply a well tested and proven performance investigation methodology, like Waits and Queues. Guessing will land you nowhere fast.

like image 107
Remus Rusanu Avatar answered Sep 22 '22 17:09

Remus Rusanu