RAID-5 is usually no slower than RAID-10, the other popular raid with both striping and parity. A partial-block write requires two reads and two write on either. Anyway, the reads and writes are cached, so it is not necessarily a full 4 IOPs.

OPTIMIZE TABLE is almost never worth doing on InnoDB, since that engine does a “pretty good” job of keeping BTrees balanced.

A simple rule of thumb for buffer_pool_size (at least for >4GB of RAM) is 70% of available RAM. You can improve on that formula, but not with a single sentence.

On a system that has been running for some time, I consider log_queries_not_using_indexes to be useless. A query that is not using an index is probably either using a tiny table, in which case it is not worth optimizing, or it is so slow that it exceeds long_query_time.

If you are connecting over a WAN, a Stored Routines can greatly speed up things by decreasing the number of roundtrips.

Looking for unused indexes is dangerous. Any technique will miss that monthly query that really needs that index that has not been used for three weeks.

Last time I checked, Fabric had a serious Single-Point-of-Failure. If the single Fabric Node dies, all clients will fail to connect to any server.

innodb_flush_log_at_trx_commit may as well be 0 on PXC/Galera — simply lose the node and rebuild it.

Isn’t O_ALL_DIRECT better than O_DIRECT?

log_bin = 0 — but wait; we are talking about replication?

sync_binlog = 0 on the Master causes a minor nasty if the Master crashes.