So I originally ran `mysqltuner` and it kept saying (on a fresh Wordpress install, using Percona InnoDB with random dummy data for Wordpress posts) that there was fragmented tables. I don't know if this is the proper way to check for fragmented tables or not:

```
SELECT TABLE_SCHEMA, TABLE_NAME, CONCAT(ROUND(data_length / ( 1024 * 1024 ), 2), 'MB')        DATA, CONCAT(ROUND(data_free / ( 1024 * 1024 ), 2), 'MB')FREE from information_schema.TABLES where TABLE_SCHEMA NOT IN ('information_schema','mysql') and Data_free > 0;

```

but that spits out:

```
+----------------+-------------+--------+--------+
| TABLE_SCHEMA   | TABLE_NAME  | DATA   | FREE   |
+----------------+-------------+--------+--------+
| db_wordpress   | wp_postmeta | 2.52MB | 4.00MB |
| db_wordpress   | wp_posts    | 1.52MB | 4.00MB |
+----------------+-------------+--------+--------+

```

So I'm unsure if those tables are truly fragmented or not. I've ran:

```
ALTER TABLE wp_postmeta ENGINE='InnoDB';

```

which supposedly is the correct way to "optimize" InnoDB tables? That then made the above query show:

```
+----------------+-------------+--------+--------+
| TABLE_SCHEMA   | TABLE_NAME  | DATA   | FREE   |
+----------------+-------------+--------+--------+
| db_wordpress   | wp_postmeta | 0.02MB | 4.00MB |
| db_wordpress   | wp_posts    | 1.52MB | 4.00MB |
+----------------+-------------+--------+--------+

```

Now, `mysqltuner` was still saying those two tables were fragmented, so I tried:

```
OPTIMIZE TABLE wp_posts;

```

When running the above query then put the "data" column back to the original of 2.52MB...

So I'm unsure what's going on exactly? Let alone why exactly the tables (particularly `wp_posts` and `wp_postmeta`) would be fragmented as my understanding was (primarily?) deletes were the big cause of fragmentation? If it's also inserts would I have fragmentation issues on pretty much every new post that's made in Wordpress considering that's what seems to have caused the tables to get fragmented in the first place?

Either way, I'm just unsure if that query above is the correct one to check for fragmentation and if so, would `ALTER TABLE wp_postmeta ENGINE='InnoDB'` or `OPTIMIZE TABLE wp_posts` be the correct query to run to optimize the table and if so why would the query still show as fragmented?

EDIT:

Percona's Config Wizard gave me:

```
# MyISAM #
key-buffer-size                = 32M
myisam-recover                 = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 16M
max-connect-errors             = 1000000
skip-name-resolve
#sql-mode                       = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY # I disabled this due to problems with WP/Plugins
sysdate-is-now                 = 1
innodb                         = FORCE
#innodb-strict-mode             = 0 # I disabled this due to problems with WP/Plugins

# DATA STORAGE #
datadir                        = /var/lib/mysql/

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

# CACHES AND LIMITS #
tmp-table-size                 = 96M # I tweaked this due to mysqltuner recommendation
max-heap-table-size            = 96M # I tweaked this due to mysqltuner recommendation
query-cache-type               = 1 # I tweaked this due to mysqltuner recommendation
query-cache-size               = 96M # I tweaked this due to mysqltuner recommendation
max-connections                = 100
thread-cache-size              = 16
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 256

# INNODB #
innodb_stats_on_metadata = 0 # I added this when testing
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 64M
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table          = 1
innodb-buffer-pool-size        = 400

```