mysql

mysql workbench

http://www.pvsm.ru/mysql/31556

Далее...

Too many open files

текущее число открытых файлов:
cat /proc/sys/fs/file-nr
показывает:
открытыеоткрытые, но не используемыемаксимально возможное количество открытых

Увеличить максимальное:
vim /etc/sysctl.conf
fs.file-max = 9999999
sysctl -p

Увеличить для mysql соответственно количество файлов и процессов:
vim /etc/security/limits.conf
mysql soft nofile 28192
mysql hard nofile 28192
mysql soft nproc 20240
mysql hard nproc 20240

Далее...

Эмпирический вывод

Увеличение количества параллельных процессов в 2 раза дает прирост производительности в 1.5 раза.

Далее...

оптимизируем и восстанавливаем таблицы mysql

Чтобы восстановить и оптимизировать таблицы можно заморачиваться с SQL а-ля REAPAIR TABLE `tbl`; и OPTIMIZE TABLE `tbl`;, а можно сделать проще.
Из баша.
Чтобы починить все таблицы базы:
#mysqlcheck -r --databases db_name -udb_user -pdb_pass

Чтобы оптимизировать все таблицы базы:
#mysqlcheck -o --databases db_name -udb_user -pdb_pass

Далее...

оптимизация удаления записей mysql

Три запроса выполняются быстрее, чем один.
Проверял на таблице из двух полей ~1 600 000 записей.
insert into `table111` SELECT `search`, `total` FROM `search_total` WHERE `search`>1007690;
truncate table `search_total`;
insert into `search_total` SELECT `search`, `total` FROM `table111`;
4,19 секунды

DELETE FROM `search_total` WHERE `search`<=1007690;
11.57 секунды.

Далее...

переход с mysql 5.0 на mysql 5.5

При переходе с mysql 5.0.x на mysql 5.5.x может возникнуть проблема при создании временных таблиц.
Вместо TYPE=HEAP надо использовать ENGINE=MEMORY

Далее...

join работает быстрее, чем in

SELECT * FROM `search` WHERE `id` in(SELECT `search` FROM `search_history` WHERE `login`='login' AND `program`='tovars_lp') ORDER BY `date` DESC LIMIT 0 , 15; - до 1.5 секунд.

SELECT *
FROM `search`
RIGHT OUTER JOIN `search_history` ON `search`.id = `search_history`.search
WHERE `search_history`.`login` = 'login'
AND `search_history`.`program` = 'tovars_lp'
ORDER BY `search_history`.`date` DESC
LIMIT 0 , 15
- 0.0045 секунды.
а если заменить * на список нужных полей, то сокращаем время запроса до 0.0015 секунды.

Далее...

Prepare

Подготовленные запросы имеются в MySQL начиная с 4.1 и нужны по трём причинам.

Скорость. Если вы выполняете однообразные запросы, то mysql парсеру каждый раз приходится выполнять распознавание - какой тип запроса, какие данные передаются и тому подобное. Если сделать прототип запроса, а в последствии передавать только данные, то ясное дело что это скажется на скорости.
Передача данных. Мало того что для подобных запросов передача бинарных данных не нуждается в конвертировании в строку, так и то что стандартное ограничение на один запрос имеет около 1 мб можно подвинуть благодаря тому что каждый кусок данных передаётся отдельным запросом, а не одним общим (INSERT скажем).
Безопасность. Благодаря отделению данных от запроса вы можете обезопасить себя от SQL injection .
PREPARE some_statement_1 FROM "INSERT INTO my_table (`some_HTML`, `some_title`) VALUES ('?','?')";
SET @someparam_1 = "HTML SOURCE";
SET @someparam_2 = "TITLE HERE";
EXECUTE some_stament_1 USING @someparam_1,@someparam_2;
DEALLOCATE PREPARE some_statement_1;

Всё достаточно просто - объявил запрос, вместо переменных поставил символы вопросов, потом по порядку этих символов объявил переменные , выполнил запрос и удалил кэширование (которое только планируется сделать).

Далее...

mysql ошибка 1075

Когда добавлял в таблицу поле, которое должно было стать ключевым и уникальным столкнулся с такой ошибкой:

#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key!

При том, что изначально при добавлении поля устанавливал его ключевым.

Решается следующим образом:
1) добавляем поле, делаем его индексным и с автоинкрементом
2) делаем его ключевым
3) удаляем просто индекс.

Далее...