Оптимизация базы MySQL : MySQL & MariaDB

Я, к сожалению, не силен в MySQL, кто как оптимизирует и настраивает базу? Вот у меня есть тут, в форуме процедура оптимизации, ужимает базу раз в 10, еще не разбирался, что делает. Может в мускуле перепаковка удаленных записей есть? Или еще что? Короче, кто что делает?

В мускуле на котором стоит УКМ нет паковки удалённых записей. Даже если дропать базу (именно базу а не таблицу!) - один хрен не изменится размер. Выход - иметь девственно чистую дб и периодически всасывать в неё из сделанного дампа.
Дамп as insert
mysqldump --opt -e -uLOGIN -PPORT -hHOST -pPASS DBNAME > dump.txt

осстановление из бэкапа
mysql -uLOGIN -PPORT -hHOST -pPASS DBNAME < dump.sql
А лучше зайти в консоль:
SET FOREIGN_KEY_CHECKS=0;
source dump.sql
SET FOREIGN_KEY_CHECKS=1;
Последняя строка не обязательна, ибо это настройка для твоей сессии.

-e в дампе очень важный параметр - восстанавливатся из дампа сделанного с этим ключом будет на порядок быстрее. Ибо он большими кусками будет такой дамп в базюку колбасить.
По идее ещё быстрей будет работать если автокоммит отключать. Но я не пробовал.
А вообще - лучше дампить так:
результат show tables выводишь в файл
mysql -uroot -hServerIP -e"show tables" >> tables

А потом пишем батник:
for /f "tokens=1" %%i in (tables) do (
C:\MYSQL\bin\mysqldump --opt -uroot -e -hServerIP ukmserver %%i >> D:\_ukmsrv\%%i
)

Восстановливать таким же образом. Если вдруг чё-то случится, не придётся запускать дамп или восстановление бэкапа по новой. Можно писать в скрипте перед дампом SET FOREIGN_KEY_CHECKS = 0.

Толковой доки по оптимизации самого сервера mysql (буферов там всяких) в общем-то и нету. Кое-что есть, но этого мало. Делается всё экспериментальным путём, долго и муторно.
А вообще, MySQL начинает очень колбасить когда много процессов на нём запущено. Когда у нас врубается репликация на шесть магазинов на сервере серверов - двухпроцевая тачка дико тормозит. С+ об этом знает и собирается сделать очередь репликаций (тут на самом деле не так всё просто как кажется - нужна ведь ещё и возможность задавать приоритеты на некоторые таблицы.)
В Оракле всё на порядок грамотнее и интереснее чем в MySQL. Оракл в плане оптимизации - мегавещь!

мегавещь! Кстати, ходят слухи о переводе на Oracle серверной части УКМ4

Слышал и про, что сервак под ЛИНУКС тестят.....

В данном случае это поможет только в плане стоимости платформы, ибо переход с винды особых преимуществ не даст.

Мое мнение - сервак под ЛИНУХ должен быть. И тогда у всяких там ОБЭП не будет повода придраться, как это случается все чаще и чаще

Такие вещи как Апач, MySql - были портированы с *nix. И MySQL уж точно быстрее виндового работать должен... Некоторые говорят в два раза. Да и пересобирать его под *никсом проще.

Приближаемся к вечному топику о преимуществах винды перед линуксом. Как сказал один товарищ:"Я не сплю с ними, я за них деньги получаю", несмотря на порт, вряд ли в 2 раза, только если использовать какие-то специфичные для платформы вещи. С тезисом, что сервер УКМ должен быть под Linux я не спорю. Должен быть. Ибо ОБЭПы и прочие русские щиты не спят, хотя жаль *05 Я сторонник свободного развития софта. Не бейте ногами, я дяде Биллу платил за винду раза два, кажется.

Процитирую кусок своего письма в тему... Ваши комментарии?
Ковырялся с настройками, если есть желание, почитайте мои рекомендации по настройке. Сам я еще чайник в MySQL, ориентируюсь просто на подобное в Oracle и надеюсь, что не будет путаницы версий.
Итак, исхожу, что то, что дали мне идентично тому, что ставится в магазах:
1) innodb_data_file_path=ibdata1:500M;ibdata2:150M:autoextend
кажется более выгодным (чем создание одного на 300, как у меня сейчас) в плане разделения их потом по дискам и возможности асинхронного чтения/записи, если таковое MySQL поддерживается. Кроме того, хорошо бы запрашивать у клиента, где именно лежит его драгоценный рейд. Диск С:, куда по умолчанию просится мускул, как раз не часто рейд, наоборот, какой-то винт для системы. Да еще и со свопом.
2) задавать бы innodb_autoextend_increment скажем метров в 100, слишком маленькое значение увеличения приведет к фрагментации, как файла данных, так и его внутренностей.
3) Логи были всего 5 метров, это маловато, у меня по умолчанию - 20Мб.
4) innodb_buffer_pool_size почему бы не выставлять в значение 80% от всей оперативки, как рекомендуется? Ну хотя бы в 250Мб, по умолчанию 80Мб, это уже морально устарело...
5) Сделал базе optimize по всем таблицам - 200-300 мс выполнение запроса. В штатные процедуры?
6) key_buffer_size увелить бы до 8Мб? На приведеной в пример базе размер всех индексов - 2Мб, ну, сделаем накидку на время и возможные ресурсы сервера...
7) думаю, set-variable=table_cache=64
8) При экспорте-импорте размер базы сократился с 1,6Гб до 300Мб (изначально заданного значения), понятно, что сканирование такого нехилого файлика при любых вывертах алгоритма поиска будет дольше. Т.е. подобная процедура должна стать штатной. Тем более, что я тоже не нашел другого способа для уменьшения размера базы.
9) innodb_file_per_table=1 ? Вместо одного гигантского файлика получаем кучу маленьких после экспорта-импорта? Доводы против?

Давайте настойками my.ini меряться? Я сегодня порядком док перешерстил, на кое-что взгляд свой поменял, обнаружил некоторые полезности, например
\mysql\bin\mysqlcheck -uroot -ppassword --repair --analyze --optimize --all-databases --auto-repair
Кое-что еще, поскольку новичок в этом деле, много для себя открытий сделал. Завтра приведу измененные параметры my.ini, может кто-то еще что менял, поделимся?