Views and virtual columns are similar, in that neither are materialized. i.e. neither store any data or indexes, hence why your index_length+data_length remain the same.
Where they differ is:
- Virtual columns are created on base tables, and will co-exist with columns which will be material. This can be useful as it has more of a mixing/matching behavior than views.
- Virtual columns permit indexes (which are materialized). Views do not.
As a side note, another commonly used feature with some overlap here is triggers. It is often better to have a virtual column than a trigger updating legacy columns on insert/update.
In response to this specific question:
How do you find the true footprint or overhead for using these?
There is no footprint, and you will likely not see overhead. Sure, there are hypothetical cases: If you have many virtual columns and SELECT * from a client then more data will be sent across the network (since rows are sent in full; clients don't know they can reconstruct certain data from virtual column definitions).