На днях прилетело обновление : Server version: 8.0.27 Gentoo Linux mysql-8.0.27 x64 и загрузка процессора от mysqld пропала совсем.
До этого постоянно тикало в районе 0.1, что не критично но разрушало чувство прекрасного, тем более помню, что до какой-то версии такого не было.

https://ru-mysql.livejournal.com/296471.html

сервер 5.7.33-0 ubuntu 0.16.04.1

SHOW FULL FIELDS FROM `test`

Field 	Type 	Collation 	Null 	Key 	Default 	Extra 	Privileges 	Comment 
str	varchar(100)	utf8_general_ci	NO	 	NULL	 	select,insert,update,references

INSERT INTO test VALUES ('А РОЗА УПАЛА НА ЛАПУ АЗОРА')

select * from test where str like '%роза%' - строка найдена
select * from test where str regexp 'роза' - строка не найдена

Проверил на нескольких кодировках, все case-insensitive, конечно.
На однобайтовых поиск правильный, ну многобайтовых LIKE работает, а REGEXP - нет.

То же самое на сервере MariaDB 10.1.28 под windows работает во всех вариантах правильно.

Проблема, как я понял, старая и общеизвестная.
Кто-либо нашел решение?
Хотя бы известно кто виноват-то, замена мускуля на марию под убунтой проблему решит или нет?

https://ru-mysql.livejournal.com/296383.html

а занимался ли кто-то этим всерьез?

т.е. я разбираю текст стеммером и добавляю новые корни в таблицу.
word, wordid
и обновляю кросс-таблицу связей
wordid, documid

все было хорошо на маленьких объемах.
сейчас у меня миллионы документов, а с количеством слов все плохо
единичные закааз меня не напрягают (возможно зря).
а вот любое число это отдельное слово. люди ищут по ИНН, сумме и еще хз чему. отказываться от этого нельзя

в общем сейчас в справочнике слов порядка 8М записей.
сколько записей в кросс-таблице я не знаю - count сделаю только в выходные, сейчас это положит базу.
индекс wordid,documid весит порядка 17ГБ.


почистить справочник слов возможно, но не в разы. а удаление закаазов вряд ли серьезно уменьшит кросс-таблицу.

поиск пока работает терпимо (в справочнике слов есть doccnt и я сортирую джойны по нему), за исключением вариантов, когда люди набирают "клиент кредит ООО" и по каждому слову миллионы пересечений
(это отдельный вопрос как победить)

добавление в кросс-таблицу уже начинает напрягать по времени перестройки индекса.
ну и основной вопрос - что она растет бесконтрольно и уже вызывает вопросы по объему памяти на сервере

https://ru-mysql.livejournal.com/295951.html

Приглашаем на серию лекций по MySQL 15-16-17 декабря в 19:00. Расскажем, что именно настроить, чтобы база не тормозила и не падала, а данные не терялись. Поможем найти медленные запросы и сделать их быстрыми. Обсудим ваши кейсы.

Ведущий Владимир Федорков, специалист по настройке и эксплуатации СУБД MySQL, эксперт в сфере производительности MySQL.

Программа мероприятия:

День 1,15 декабря, вторник: Ставим и тюним MySQL для работы с высокими нагрузками

• Версии MySQL и форки


• Как настраивать MySQL? Важные аспекты при установке и первоначальной настройке


• Как работает MySQL? Архитектура и настройки InnoDB


• Другие подсистемы хранения


• Что не нужно настраивать никогда


• MySQL tuner и другие скрипты автоматической настройки

День 2, 16 декабря, среда: Учимся писать самые быстрые в мире запросы для MySQL

• Запросы в MySQL: что влияет на производительность?


• Как оптимизировать SELECT?


• Оптимизатор MySQL


• Selectivity и Cardinality – главные слова, которых никто не знает


• Кэш запросов в MySQL


• Оптимизация записи


• Работа с изменениями схемы

День 3, 17 декабря, четверг: Строим отказоустойчивую инфраструктуру для MySQL

• Работа MySQL под высокими нагрузками


• Масштабирование MySQL


• Функциональное шардирование


• Горизонтальное шардирование


• Репликация в MySQL


• Master-Master репликация


• Инструменты объединения MySQL в кластеры (Galera, Group Replication)


• Маршрутизация запросов и ProxySQL


• Управление репликацией: MHA и Orchestrator


• Бэкап и восстановление

Продолжительность каждого занятия — 1 час, начало в 19.00 МСК.

В конце каждого дня выделяется 15 минут на вопросы и разбор кейсов участников. Видеозапись тоже будет доступна.

Стоимость участия за три дня — 3 000 рублей.

Сделано в сотрудничестве с центром обучения Слёрм.


Посмотреть программу еще раз и подать заявку

https://ru-mysql.livejournal.com/295764.html

Банальность, есть пара таблиц - группы и привязанные к ним элементы, примерно 2.5К групп, 3.3М элементов. Часть групп пустая.
--- группа ---
gr_id int
name varchar(64) utf8_general_ci

--- элемент ---
el_id int
group_id int
code varchar

Нужно получить все группы с количеством элементов в них.

SELECT groups.*, count(el_id) as cnt FROM groups left join elements using (gr_id) GROUP BY gr_id
Нормально, выполняется за 150 мс

SELECT groups.*, count(el_id) as cnt FROM groups left join elements using (gr_id) GROUP BY gr_id ORDER BY name
Выполняется за 50 _секунд_
Медленее в 300 с хреном раз.

SELECT * FROM
(
SELECT groups.*, count(el_id) as cnt FROM groups left join elements using (gr_id) GROUP BY gr_id
) as q
ORDER BY name
Выполняется за те же 50 секунд

$%^, ПОЧЕМУ?! Моя фантазия пасует.
Сортировка должна выполняться на полностью сформированной выборке.
Сортировка 2к5 строк не занимает минуту. Ни при каких раскладах.

https://ru-mysql.livejournal.com/295589.html

Здравствуйте!

MySQL 5.7.25, innodb, Linux

При запуске OPTIMIZE TABLE создаёт временный файл в той же директории где лежит таблица. А для скорости хочется что-бы временный файл можно было создать на другом диске.
Переменные tmpdir, innodb_tmpdir, именно на OPTIMIZE TABLE не влияют.
Чисто для опыта попробовал включить путь в префикс временного файла
#define TEMP_FILE_PREFIX_INNODB "#sql-ib"
Но чуда не произошло, т.к. созданный файл потом переименовывается в место старого, а rename (); не умеет с другой fs.

Как бы такое правильно сделать?

https://ru-mysql.livejournal.com/295222.html

11 июля в 18:00 в офисе компании Mail.Ru состоится очередная встреча Moscow MySQL User Group. Специальный гость встречи - Пётр Зайцев (CEO, Percona). Пётр сделает два доклада и ответит на вопросы участников встречи. Вход свободный. Регистрация здесь: https://www.meetup.com/moscowmysql/events/240684527/

Программа встречи

1. Обеспечение высокой доступности (HA) СУБД MySQL.

2. MySQL в облаке: миграция, лучшие практики, высокая доступность и масштабируемость.

3. Ответы на вопросы аудитории.

https://ru-mysql.livejournal.com/294958.html