Thanks for the feature requests. It would be quite helpful if different feature requests end up in different JIRA items. Can you edit this down to just the first feature, adjust the title (searchability helps) and put the other items in a separate ticket now.

Can you also include more information in the individually created tickets as to why and under what circumstances the feature is useful, and if other features/functions exist within the relm of the problem, why they aren't a sufficient solution.

Please keep in mind that the identifier names are being stored in some persistent data structures where there may be surprising limits. One such place are the tables mysql.innodb_index_stats and mysql.innodb_table_stats, especially when using innodb_page_size=4k. The maximum length of an identifier there is already some 4*5*64 characters, plus some delimiters /, #P#, #SP#. The filename-safe encoding can expand each utf8mb3 character up to 5 ASCII characters. To storage engines, each partition or subpartition of a table is presented as a separate table, whose name consists of up to 4 components: schema, table, partition, subpartition name. If we implement catalogs (multi-tenancy), a 5th component (catalog name) will have to be added somewhere.

It's not a huge task, I think, but the one where it's difficult to predict what it'll affect. Lots of places make assumptions about the max identifier length. All system tables, InnoDB data dictionary, frms, file names, protocol, perhaps, too, and lots of internal data structures. Most of the internal data structures will auto-adjust, for sure. But going from 64 to 1000 might notably affect the heap and stack usage.

Then, why don;t you go with 100 or 128? Better than 64.

Yes, better. I think we could try to go to a larger number first, like, 1000, and if it'll cause too many problems that we won't be able to fix, then 128 could be an option.