ru_mysql (original) (raw)
ошибка regexp на мультибайтовых кодировках
сервер 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 работает во всех вариантах правильно.
Проблема, как я понял, старая и общеизвестная.
Кто-либо нашел решение?
Хотя бы известно кто виноват-то, замена мускуля на марию под убунтой проблему решит или нет?
15–17 декабря серия лекций «Тюнинг и масштабирование проекта на MySQL»
December 8th, 2020
Приглашаем на серию лекций по MySQL 15-16-17 декабря в 19:00. Расскажем, что именно настроить, чтобы база не тормозила и не падала, а данные не терялись. Поможем найти медленные запросы и сделать их быстрыми. Обсудим ваши кейсы.
Ведущий Владимир Федорков, специалист по настройке и эксплуатации СУБД MySQL, эксперт в сфере производительности MySQL.
April 14th, 2019
Здравствуйте!
MySQL 5.7.25, innodb, Linux
При запуске OPTIMIZE TABLE создаёт временный файл в той же директории где лежит таблица. А для скорости хочется что-бы временный файл можно было создать на другом диске.
Переменные tmpdir, innodb_tmpdir, именно на OPTIMIZE TABLE не влияют.
Чисто для опыта попробовал включить путь в префикс временного файла#define TEMP_FILE_PREFIX_INNODB "#sql-ib"
Но чуда не произошло, т.к. созданный файл потом переименовывается в место старого, а rename (); не умеет с другой fs.
Как бы такое правильно сделать?
Встреча Moscow MySQL User Group 11 июля в офисе Mail.Ru Group
June 30th, 2017
11 июля в 18:00 в офисе компании Mail.Ru состоится очередная встреча Moscow MySQL User Group. Специальный гость встречи - Пётр Зайцев (CEO, Percona). Пётр сделает два доклада и ответит на вопросы участников встречи. Вход свободный. Регистрация здесь: https://www.meetup.com/moscowmysql/events/240684527/
Программа встречи
1. Обеспечение высокой доступности (HA) СУБД MySQL.
2. MySQL в облаке: миграция, лучшие практики, высокая доступность и масштабируемость.
3. Ответы на вопросы аудитории.
Секция MySQL на PG Day’17 Russia (Санкт-Петербург)
May 13th, 2017
В рамках PG Day’17 Russia состоится полноценный поток докладов и мастер-классов, посвященный MySQL и другим открытым базам данных: https://pgday.ru/ru/2017/papers
Ключевым событием для специалистов, занимающихся эксплуатацией MySQL, станут мастер-классы от ведущих экспертов компании Percona, Петра Зайцева и Светы Смирновой.
Петр Зайцев является основателем и CEO Percona, обладает более чем 15-летним стажем работы с MySQL и поддержки СУБД для крупнейших представителей бизнеса. В рамках PG Day'17 Петр представит учебный курс, посвященный архитектуре и оптимизации производительности InnoDB. InnoDB — наиболее часто используемая подсистема хранения для MySQL и Percona Server, на которую направлены основные усилия разработки команд MySQL и Percona. Петр расскажет, как использовать InnoDB, чтобы добиться максимальной производительности вашего приложения, и предложит конкретные рекомендации относительно конфигурации сервера, схемы базы данных, архитектуры приложения и выбора оборудования.
Света Смирнова обладает 10-летней экспертизой технической поддержки MySQL, является автором книги MySQL Troubleshooting и мировым экспертом по архитектуре и оптимизации производительности этой СУБД. На PG Day'17 участников ждет интенсивный 8-часовой учебный курс, посвященный отладке производительности MySQL. В рамках мастер-класса Света покажет, на основе личного опыта работы в технической поддержке, простые в использовании методы, позволяющие определить и устранить причины нежелательного поведения MySQL. Вы узнаете, какие инструменты и в каком порядке удобно использовать, с чего начать и как углубиться в проблему, научитесь безопасно тестировать свой сервер СУБД.
Вас также ждет множество интересных докладов от специалистов компаний MongoDB, Percona, МТС, Elastic, КРОК, Яндекс, Mail.Ru Group, Epam, Data Egret и др. Регистрируйтесь: https://pgday.ru/ru/2017/request/registration
Кто это локально ломится под рутом без пароля?
September 25th, 2016
Каждые пять минут в логах (/var/log/mysqld.log) появляется такое:
2016-09-25T22:48:10.512240Z 18873775 [Note] Access denied for user 'root'@'localhost' (using password: NO)
2016-09-25T22:53:00.526894Z 18874007 [Note] Access denied for user 'root'@'localhost' (using password: NO)
2016-09-25T22:58:01.353671Z 18874265 [Note] Access denied for user 'root'@'localhost' (using password: NO)
Грешил на что-то вебовское или на cron job, поэтому временно убил обоих демонов:
systemctl stop httpd
systemctl stop crond
После этого подождал пять минут, и, как ни в чем ни бывало, появилось очередное аксесдинайд.
Что это такое и как прекратить? Операционка CentOS 7.1, сервер mysql 5.7. Спасибо!
P.S. Оказалось, это был webmin. Вопрос снимается.
June 26th, 2016
режь последний огурец.
160626 14:23:52 [ERROR] \usr\local\mysql-5.5\bin\mysqld.exe: Out of memory (Needed 16384 bytes)
Напихал в машину оперативки до 4 гигабайт. Разрешил мускулю побольше.
key_buffer_size = 1G
max_allowed_packet = 8M
table_open_cache = 512
sort_buffer_size = 1G
read_buffer_size = 1G
read_rnd_buffer_size = 256M
myisam_sort_buffer_size = 1G
thread_cache_size = 64
query_cache_size = 256M
Фактически mysqld не занимает более 1 гига, в машине еще полтора-два свободно.
Тем не менее постоянно вижу в журнале такую ошибку.
Что забавно: при попытке перекинуть данные из таблицы (большой) в другую
insert into tbl1 select * from tbl0
появляется _ошибка_ out of memory и операция сбрасывается.
А вот при сортировке или перестройке индексов эти ошибки пишутся в журнал именно как ERROR, но учитываются как предупреждения - warnings.
Можно как-нибудь понять кому и для чего не хватает памяти?
UPD. Что-то здесь концы с концами не сходятся
Взял из комплекта "денвера" конфиг мускуля
This is for a large system with memory of 1G-2G where the system runs mainly
MySQL.
key_buffer_size = 512M max_allowed_packet = 4M table_open_cache = 512 sort_buffer_size = 256M read_buffer_size = 256M read_rnd_buffer_size = 256M myisam_sort_buffer_size = 512M thread_cache_size = 64 query_cache_size = 256M
В машине 4 гига, кроме мускуля ничего не запущено. Ну, подойдет.
Объем памяти, занимаемой mysqld, не превыcил 800М. Хотя уже сообразно конфигу должно быть больше.
В машине еще 2 гига свободной оперативки.
Однако же "out of memory error".
Ладно, берем из того же комплекта другой образец.
# This is for a large system with memory = 512M where the system runs mainly
# MySQL.
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
Таки key_buffer_size=256M. Надо ожидать, что mysqld будет не меньше. Однако же размер mysqld жестко ограничивается 80М и все работает феноменально медленно.
Ну то есть вообще неприемлемо. Поставил таблицу на сортировку. 120М строк. Пришел на следующий день - едва ли на 3/4 выполнено.
Поднял немного лимиты.
key_buffer_size = 256M
max_allowed_packet = 2M
table_open_cache = 256
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 128M
thread_cache_size = 8
query_cache_size= 16M
Запрос "insert into p2 select * from parts order by de_mas, ra_mas;"
Пока идет выборка и сортировка show processlist -> sorting result - памяти забирает примерно 80-90 М. На этапе внесения в новую таблицу - уже 1.5G и похоже, что этим не ограничится.
Почему mysqli_multi_query() в PHP возвращает управление раньше, чем заканчивает выполнение запросов?
March 24th, 2014
Строго говоря, вопрос, наверное, про функцию mysql API mysql_real_query() - поскольку пхпшная - всего лишь обертка над ней.
Если я запускаю mysqli_multi_query() с 1000 инсертов, то и в случае myisam, и в случае innodb таблиц функция возвращает управление мгновенно.
однако в innodb стоит по умолчанию innodb_flush_log_at_trx_commit = 1 - и на самом деле запись идёт медленно, что видно даже по select(*) - примерно по 100 req/sec.
И цикл more_results()/next_result() занимает те же 10 секунд.
При этом если вместо одно мультизапроса запускать в цикле mysqli_real_query(), которая так же является оберткой над API шной mysql_real_query(), но только с отрубленной возожностью выполнять мультизапросы, то выполнение занимает опять же 10 секунд.
Собственно, вопрос: я правильно понимаю, что мгновенный возврат управления - это исключительная фича Multiple Statement Execution, а не mysql_real_query() или какой-то другой функции?
5.5.35-MariaDB, PHP 5.5.9, mysqlnd, Fedora 20.
MySQL DBA и MySQL Developer сертификаты по 50$
October 8th, 2013
Всё лето MySQL Support Team и Oracle Certification, при некоторой поддержке других отделов, работали над новым экзаменом по MySQL 5.6. Наконец работа завершена и стала доступной beta-версия экзамена. Beta-программа начнётся 28 октября и продлится 8 недель. Именно в это время у вас есть шанс получить сертификат за 50 долларов США. Подробнее о beta-программе и о том, как записаться на экзамен, здесь.