6

I'm getting this error:

Row Size Exceeding 65535

There are a lot of posts out there discussing the maximum row size in catalog_product_flat_x exceeding 65535 bytes. I have only about 150 attributes including the double entry _values for the select attributes. If all attributes were 255 bytes (which they aren't), the maximum number of bytes that I could have is 38,250 bytes far less than the 65,535 byte limit. The actual data in each row is significantly lower than that.

I deleted all of the catalog_product_flat_x tables, reindexed and am still getting this crazy error. I am on my way to having 4000 products and need this capability.

Any insight would be helpful

Improve this question

2 Answers 2

Reset to default
6

It is not depending on what your rows really hold for data but what is possible. According to official MySQL documentation https://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html

The maximum row size constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size. For example, utf8 characters require up to three bytes per character, so for a CHAR(255) CHARACTER SET utf8 column, the server must allocate 255 × 3 = 765 bytes per value. Consequently, a table cannot contain more than 65,535 / 765 = 85 such columns

So you hit the wall way faster than in your example

Improve this answer
4

If your data exceeds the row size available, your options are limited. I've documented this personally here, https://www.sonassi.com/knowledge-base/magento-kb/mysql-limitations-on-the-flat-catalogue-in-magento/

Ultimately, at 4,000 products - I'd expect to see negligible improvements when using catalog_product_flat anyway - so I wouldn't think its worth pursuing.

Improve this answer
4
  • I used to deactivate it in a shop with more than 50k products because of the attribute hell that broke loose and there where not so many heavy negative side effects. Its just important to look if everything that is indexing (likely some nice 3rd party modules on ->save() calls/observers) is turned off because otherwise you still have the indexes running and failing and nothing happening.
    – Nils Preuß
    Commented Jul 7, 2015 at 6:41
  • Ben/Nils - thanks for the great feedback. I posted the same question on the new Magento Forum and got no response. I guess this is still the best place to get answers from knowledgeable guys. I do in fact have 82 Char(255) columns. So MySQL is reserving space whether I use it or not? Seems like poor magento and database design. Good it hear it isn't really needed anyway.
    – WilliamD
    Commented Jul 8, 2015 at 17:59
  • Update: I do have 82 varchar(255) but those are variable length columns and shouldn't take up any space if they aren't used right? I have about 100 attribute sets and many of the attributes are not used in each set. Still the category_product_flat table has a column for each attribute. I guess it is good to know that it is not required anyway.
    – WilliamD
    Commented Jul 8, 2015 at 18:12
  • Did any of the above helped solving your problem or getting more insight? Then accepting is the right move.
    – Nils Preuß
    Commented Jul 28, 2015 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.