When is tuple length too long?

Here is a logical schema for my largest relation:

{(id, uName, supplies, score, playerType, storageSupplies, supplyDrop, barracks, armourDepot, hangar, droneHangar, storage, offensive, defensive, infantry, vehicles, air, fuel, explored, morale, cash, population, tax, food, aSector, cSector, iSector, XP)}

As you can see, each tuple is going to be very long. This is starting to become very cumbersome as attributes are added. The thing is, there is only ever a 1-to-1 relationship so while it would help organisation and avoid obfuscation by breaking this relation up into sm开发者_运维知识库aller, meta related relations, wouldn't it add more overhead? Or should I not worry about mysql efficiency when this relation will have tens of thousands of tuples at the most, realistically.

1) Assuming your table is max 10k rows, rarely updated and rarely read (compared to other entities in the database) - you are right efficiency will see no great benefit, however...

2) Every little bit counts; for example with table this small most of it can be kept in memory and you will have very fast SELECTS; if a lot of attributes are mostly NULLS then splitting the table would reduce the SIZE of it and would free RAM for other caches; reduce necessary I/O when updating (generally make the things more scalable). The expense is the slight increase of complexity (for updates, SELECTS can use a VIEW).

3) 'Overhead' for splitting 1-to-1 relations is misconception; it largely depends on the workload - you can construct cases that prefer things broken down into two smaller tables and you can construct cases that benefit from having the data stored in one table.

The internal representation of a table has a maximum row size of 65,535 bytes

Eficiency depends on the MySQL version and the Storage Engine you are using. But you should know that doing this will increase data to be cached that might not be necesary.

For example, a Users table might increase if we add address data of users, and that data maybe is not needed frequently, so, spliting it into 2 tables: Users and Users_address will be more efficient becouse if the table Users is heavily read it could be cached.

There are other considerations like maintenance and index work.