Urgent question: There are 1.2 million pieces of data in the table with ten fields, three of which are 99% empty. Is this appropriate?

.
Now I am facing a quite complex business logic, so I try to cut it off with an intermediate table -
It is initially estimated that this intermediate table has 1.2 million pieces of data, but for business needs, this table actually Two types of data are stored: one for each user, one for weekly/monthly/quarterly statistics, and status identification type. (See table structure below)
Therefore, the latter category (three fields) of most data is empty. (I looked at other tables in the database and found that quite a few fields had values ​​of 0 or NULL, which is why I came up with this bad idea)

Approximate table structure (not rigorous):
| userId | groupId | status | sales(99% empty) | createTime(99% empty) | lastTime(99% empty) | endTime(99% is empty) |

Want to know more about :

1. Will this amount of empty fields have an impact on efficiency?

2. In addition to sub-tables, are there any solutions?

Does this kind of table design work require a back-end program? Full of powerlessness.

Reply content:

.
Now I am facing a quite complex business logic, so I try to cut it off with an intermediate table -
It is initially estimated that this intermediate table has 1.2 million pieces of data, but for business needs, this table actually Two types of data are stored: one for each user, one for weekly/monthly/quarterly statistics, and status identification type. (See table structure below)
Therefore, the latter category (three fields) of most data is empty. (I looked at other tables in the database and found that quite a few fields had values ​​of 0 or NULL, which is why I came up with this bad idea)

Approximate table structure (not rigorous):
| userId | groupId | status | sales(99% empty) | createTime(99% empty) | lastTime(99% empty) | endTime(99% is empty) |

Want to know more about :

1. Will this amount of empty fields have an impact on efficiency?

2. In addition to sub-tables, are there any solutions?

Does this kind of table design work require a back-end program? Full of powerlessness.

If the field will not be used, just remove it
If it is likely to be used, it is not a big problem. It will not affect the query by specifying the required fields when querying