Prevent the collision data because duplicate id from imported database MariaDB
A few options: Allocate different ID ranges for each user, use composite primary keys, use UUIDs or use some of the mechanism that enables the auto_increment feature to be used in master-master replication: 


You can specify a different AUTO_INCREMENT position when you create the tables for each individual employee's database so that there is a range of IDs allocated for each employee. E.g. 

CREATE TABLE electronic_parts (
  id INT USIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  electronic_part_name VARCHAR(40), 
  kind_of_electronic_part INT UNSIGNED
) AUTO_INCREMENT=1000;



This is probably not a good idea as there is nothing to prevent over-zealous employees from creating so many records that they end up in someone else's range. (Though I suppose you could build a constraint into your application to avoid such collisions.)


Re-design the primary keys so that they become composite keys with one auto-incrementing key as you have already and one key that is unique for each employee. E.g..: 

CREATE TABLE electronic_parts (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
  employee_id INT UNSIGNED NOT NULL, 
  electronic_part_name VARCHAR(40), 
  kind_of_electronic_part INT UNSIGNED,
  PRIMARY KEY (id, employee_id) 
);


You application then has to populate the employee_id with a unique value for each employee. E.g.:

INSERT INTO electronic_parts (
  employee_id, electronic_part_name, kind_of_electronic_part
) 
VALUES (156901010, 'switch', 1);


Thanks to the auto-incrementing id component of the primary key, you don't have to worry about populating that.


Once it's time to merge all the databases, all will be fine because the primary keys are composites with one component unique for each employee, and one component unique within each individual database, so together this makes each primary key value unique across all databases.   

I've tested this successfully in MariaDB 10.2.


Use the UUID() or UUID_SHORT() functions to generate globally unique primary keys instead of auto incrementing primary keys. Your application then needs to either explicitly call one of these functions when creating the records, or you could use a trigger. (I personally think it's bad design to use triggers this way, but it does work.)  
Assuming you know a fixed upper limit to how many users there will be (n): You can use auto incrementing primary keys and set auto_increment_increment to n, and then set auto_increment_offset to 0 for the first user, 1 for the second user, 2 for the third user, and so on. This way you will avoid collisions in the same way that auto_increment is used in Galera clusters and other master-master replication configurations.