Each Row size of a table in mysql?

It's a little more complicated than that.  More details here: https://dev.mysql.com/doc/refman/5.7/en/storage-requirements.html

The internal representation of a table has a maximum row size of 65,535 bytes, even if the storage engine is capable of supporting larger rows. This figure excludes BLOB or TEXT columns, which contribute only 9 to 12 bytes toward this size. For BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer.

Else it is possible to find the biggest column which takes huge size and sort the table by size of it

I'm just curious to know what may cause such a requirement? Can something else be done?
Though this may not be a helpful comment, but curious.

"Query avoided is query optimized"

Basically saving images as base64 url as blob clolumn in one case and saving the entire uploaded file in blob column in another case. Now the user wants to retrieve the top 10 files or the top 10 base64 url which takes huge space in the entity or table?

So instead of sorting the blob we can sort the size column. Is that right? if yes, that sounds a valid idea. Please help me with your comments if any so that we can mark this as resolved.

Olaf...What KV said seems to be a valid suggestion and what you think about it? If that is valid, adding a column is not a big issue and we can easily resolve this problem. What you think?

Blobs are the things which you should touch only when you need them, very costly operation. If you may store blob file's sizes in a column, index it, all you need is select id from table order by blob_size desc limit 10 and then you may fetch those 10 images from id.

Thanks KV for the suggested solution and thanks Olaf for the alternative.

The way blobs are stored separately from the normal data makes it unideal to fetch them, yes, but it depends, octet_length() might actually get the information about the blob size from the bytes pointing to the blob. This isn't necessarily just a pointer. So in the end this size column already can be part of the blob data.

For example in InnoDB, this is illustrated quite nicely here: https://mysqlserverteam.com/externally-stored-fields-in-innodb/ in the paragraph BLOB Reference.

This reference data contains the blob size and thus the external storage of the blob isn't accessed to determine the length of the blob.

Depending on the storage engine you use for your tables this varies. But in case of InnoDB you may not need an extra size column you fill manually.

Sorry for coming back late and thanks for considering my answer as an assisted solution.

Bye, Olaf.

Olaf that's informative and thanks for your very nice explanation about it....I didn't new that..I thought when we execute the length of the row it would be expensive...Now it is clear that it won't be in the real case...Thanks for the details