You could split the table into two and can avoid code changes by creating a
view which matches what code is looking for.
I think loading few fields vs 254 into memory will make a difference but if
your select statement only have specific fields you want and not the whole
row (and also given the fact that you have index on the field you are using
to search record), I don't think it can make a difference.
But I will looking forward for more answers to your question.
On Wed, May 14, 2014 at 8:05 AM, Larry Martell <larry.martell@stripped>wrote:
> We have a table with 254 columns in it. 80% of the time, a very small
> subset of these columns are queried. The other columns are rarely, if
> ever, queried. (But they could be at any time, so we do need to
> maintain them.). Would I expect to get a marked performance boost if I
> split my table up into 2 tables, one with the few frequently queried
> columns and another with less frequently queried ones? Doing this will
> require a lot of code changes, so I don't want to go down this path if
> it won't be beneficial. Can folks here offer their experiences and
> learned opinions about this?
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql