First check if your server support partitioning by running this query:
-> PLUGIN_NAME as Name,
-> PLUGIN_VERSION as Version,
-> PLUGIN_STATUS as Status
-> FROM INFORMATION_SCHEMA.PLUGINS
-> WHERE PLUGIN_TYPE='STORAGE ENGINE'
partionning state should be active
if not run this another query to ...
I don't see any point in the HASH partitioning layer here. You might reduce the index tree height by one level, but only by adding another level to the partitioning "tree" height, which is not going to be a positive trade off.
You could get a benefit for doing index maintenance, if you sorted the bulk rows by their future hash partition before ...
Physically each partition is stored a separate data structure, and only the Query Optimizer knows that they make up one logical table.
So you shouldn't expect a significant difference in inserting into one partition or another.
If your table is a clustered index it can be more expensive to insert into the "middle" than the "end", but that'...
After reading the docs in the course of putting together this question, the answer is it's not possible to add columns to partitions that don't exactly match the columns of the parent table. From the docs on DDL Partitioning Limitations:
Partitions cannot have columns that are not present in the parent. It is neither possible to specify columns when ...