title: SQL Server performance issues with very wide tables (400 columns). Need clarity on vertical partitioning?
body: <p>I have a table with around 400 columns (4-5 million rows on average) and it has horrible performance even for count(*) or select x from y queries. The complicated queries that took seconds on a similar 30 columns table take hours on this even when the columns being accessed are same.</p>
  
  <p>The obvious solutions I see are normalization, adding indexes and vertical partitioning. In this case, normalization is not possible because these extra columns are more or less random numbers and narrations related to each record. I am going to be adding indexes on the most used columns.</p>
  
  <p>Now my questions are about vertical partitioning. I can divide the 400 columns into smaller tables, let's say 10 tables of 40 columns each. But -</p>
  
  <ol>
  <li><p>Firstly, is there any real performance benefit of such vertical partitioning at all, considering all those tables will always be joined back for querying?</p></li>
  <li><p>If there is a performance benefit, then what should be the criteria of partitioning? Should I just put the columns that are going to be mostly null, in the new tables? Or should I put the least frequently used columns, in the new tables? Or should I try to create the new tables so that the total row size of each table stays less than 8000 bytes?</p></li>
  </ol>
  
  <p>The above approaches are what I found after many hours of searching. Any other approaches that work better for wide tables will be appreciated as well.</p>