Долго я мучался со сборкой этой субд, но тем не менее я её таки поднял из исходников (в моей системе её можно установить только собрав MySQL из исходников)
По умолчанию я запользовал my.cnf.small он казался наиболее подходящим. Однако многие вещи были принесены в жертву уменьшению потребления памяти, в результате сайт получаился даже почти без контента безмерно тормозным (не гугловские скорости) можно конечно винить во всём оборудование, селер с 1.6 гигагерцем и 1 гб оперативки - это не фонтан, памяти почти нету, это факт, однако вывернуться из получившейся ситуации получилось, не скажу что конфиг - это панацея, но сайт ускорился значительно, всё таки у wordpress одним из узких мест является именно БД.
Вот примерно такой у меня конфиг для БД, не идеальный конечно же, но работает относительно быстро...
**[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 1
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 32M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 32
myisam-recover = BACKUP
max_connections = 128
max_user_connections = 64
back_log = 256
max_allowed_packet = 1M
net_buffer_length = 32K
net_read_timeout = 12
net_write_timeout = 15
wait_timeout = 30
preload_buffer_size = 384K
read_buffer_size = 1M
read_rnd_buffer_size = 192K
table_cache = 128
thread_concurrency = 3
max_sort_length = 32
join_buffer_size = 256K
transaction_alloc_block_size = 32K
transaction_prealloc_size = 32K
sort_buffer = 8M
record_buffer = 4M
max_join_size = 100K
query_cache_limit = 1M
query_cache_size = 32M
query_cache_type = 1
expire_logs_days = 10
max_binlog_size = 100M
skip-bdb
skip-innodb
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
skip-ndbcluster***
*счас вроде скорость меня более-менее устраивает, на 100 мегабитной сети. Судя по всему, дело по бОльшей части упирается именно в скорость рендеринга, однако остаётся ещё скорость отдачи (не полная утилизация канала при большом количестве маленьких объектов) - там не всё шоколадно, но это уже проблемы взаимодействия apache+nginx и тюнинга того же nginx, тут нужно ещё поэкспериментировать, тем более что например весь стэк LAMP+N лежит на одной тачке, так что в момент запроса нагрузку на проц создают все приложения из этого стэка, а поскольку всех одновременно обслужить процессор не может, (1 ядро, несмотря на многозадачную, многопоточную систему в каждый момент времени выполняется только одна задача), можно отхакать сам Wordpress, но это не наш метод :)
у этой истории будет продолжение, в котором я опишу оптимизацию nginx и пару настроек апача...