Mysql – How to force MySQL Workbench to use constraints in the file

This is an arguable opinion, from limited personal experience.

I believe it was the Workbench who screwed up the process of round trip engineering several times. I don't remember all the detail, but it certainly synchronized more objects than had actually changed. It silently deleted some data a few times. And it sometimes generated SQL that the server rejected. It was a development DB, no big deal, especially compared to the benefits. But in production I'd rather refrain from being at such a tool's mercy.

Some other people's experience was similar, e.g., MySQL Workbench model/source synchronize issue

So for a production DB there may be risks, including that of losing your data. I would stick with phpmyadmin and do synchronization back into the model, always checking what the Workbench is going to do. Keeping the model just for reference.

The .ibd files will be under the innodb_data_home_dir under a subdirectory, the subdirectory name matching the database name.

Given innodb_data_home_dir=/etc/local/mysql/data and innodb_file_per_table is set:

 SHOW VARIABLES LIKE 'innodb_data_home_dir'
 SHOW VARIABLES LIKE 'innodb_file_per_table'

then when table test.mytable is created, the .ibd file will be located in /etc/local/mysql/data/test/mytable.ibd

(It's possible that the ibdata1 file will grow to accommodate rollback for transactions. When a transaction is run, pre-change copies of blocks get recorded, in case you issue a ROLLBACK, and also for the benefit of concurrent transactions (with an appropriate isolation levels), that need to reference only committed changes, and not any uncommitted changes.)