innodb_buffer_pool_size, optimize and mysqltunner
innodb_buffer_pool_size

No; wrong approach.

Simply set innodb_buffer_pool_size to about 70% of available RAM.

If you make it too much larger than that, you risk swapping, which hurts performance terribly.

If you make it too much smaller than that, your queries run slower.

If you have a lot more data than that, you will simply hope that the "working set" is smaller, and the performance will still be good.

If you have a lot less data than that, you are wasting some RAM that you won't be using anyway.

Fragmentation

Bogus.

There are at least 3 ways in which InnoDB fragments.  The available metrics measure only one of them.

Fragmentation has very little to do with performance.  So, as long as you are not threatened with running out of disk space, don't defragment.  Furthermore, promptly after defragmenting, the freed up space will be quickly gobbled up.  The encouraging thing is that the used space will stop growing as fast after it gets to some steady state.

Catch 22:  If you are about to run out of disk space, you probably can't run OPTIMIZE because it needs space to run!

OPTIMIZE TABLE

Ignore their advice; never use it for InnoDB tables.

It copies the table over, thereby removing any "free" space because the copying compacts things better.  But, I repeat, this only squeezes out some of the "free" space.

Well, OK, there are rare cases where OPTIMIZE is useful.  However, MysqlTuner "cry's wolf" a lot on this item.

innodb_buffer_pool_instances

Simple; don't worry.

Just set it to an integer that is innodb_buffer_pool_size/1G, but no less than 1 and no bigger than 16.  No risk.  But, also, virtually no gain.  In a very busy system, it may speed things up by only a few percent.  If you have a very busy system, you need to be looking at other ways to avoid falling off the cliff.

The application probably does not mention it because either (1) they did notice it when it was added (MySQL 5.5), or (2) they realized it did not matter much.