Почему запрос не использует cache?
v muzee
vitaly_il
Есть MySQL 5.7.16 на Убунте, который используется как бэкенд для Wordpress.
Куча криво написанных запросов, но после того, как я активизировал cache, большинство запросов выполняется из cache.
Но один почему-то cache не использует.
Заранее спасибо за помощь!

ПодробностиCollapse )

Кто это локально ломится под рутом без пароля?
Sphinx
m_ike
Каждые пять минут в логах (/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. Вопрос снимается.

point, polygon
1
white_thesis
попробовал spatial ext если кому интересны результаты экспериментаCollapse )

ну, раз пошла такая пьянка
1
white_thesis
режь последний огурец.
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 и похоже, что этим не ограничится.

кстати, как бы это сделать
1
white_thesis
Не первый раз сталкиваюсь с задачей такого типа
Надо пробежаться по таблице и сделать замены вида
if (col_a == 255) set col_a = null;
if (col_b == 0) set col_b = col_c/3;
if (col_z < 0) set col_z = 200;
Независимые замены в каждой строке.

Это же можно как-то сделать за один прогон по таблице?
Одним update-ом, а не тремя ( в данном примере ).

partition tables, итоги
1
white_thesis
Текущий вариант таблицы: дробление range, нарезана на 360 кусков на 1 градусу долготы.
Координаты в mas, I*4, два независимых индекса по долготе и по широте.

Оказалось крайне важным предварительное упорядочивание данных.
Если в сегментах строки уложены в порядке по широте (ORDER BY latitude, longitude), то среднее время выборки объектов по площадке 12х12 минут составляет 80+/-30 милисекунд.
А если же данные были уложены по долготе (ORDER BY longitude, latitude), то 5-7 секунд. На два порядка больше.
Это при прочих равных.

Таблица MyISAM. Проверял как это будет на InnoDB. Сделал вариант, влил 1 гиг для теста. Время выборки оказалось примерно на порядок больше, чем для абсолютно такое же таблицы ISAM.

Очередной раз вижу преимущество узкоспециалированных инструментов над универсальными.

В оригинате данные представлены 900 бинарными фпйлами fixed records length и 1 весьма примитивный индекс на 10 мегабайт (всего-то!). Плюс крошечная програмка на фортране в 1000 строк вместе с комментариями. Всего 8 гиг. Для некоторых полей применена "познаковая" упаковка.

В виде мускуль-таблицы это 11 гиг (9 данные и 2 индексы).

Время выборки примерно такое же.

partition tables
1
white_thesis
У меня появился повод поразбираться с этой фичей. На слабой машине нужна работа с большой таблицей 120кк строк, 14G байт . Записи - объекты с географическими координатами, выборка обычно делается по очень компактной области координат и иногда по идентификатору объекта. Таблица используется только на чтение. Мускуль 5.5

То есть просто напрашивается на разделение на N таблиц по диапазону одной из координат.
create table qwe
(
ident int not null comment 'уникальный код объекта'
lat decimal (10,8) not null comment 'широта',
lng decimal (11,8) unsigned not null comment 'долгота',
...
unique (ident),
index (lat),
index (lng)
)
partition by range (lat)
...
реальная конструкция таблицы - многабуквCollapse )

На практике я, разумеется, столкнулся с непонятным поведением.
К примеру, мускуль не желает делать дробную таблицу, покуда есть unique индекс по идентификатору. Просто index - приемлет. Не, ну в данном случае мне никто не мешает заменить тип индекса. Это мелочи, хотя и странные.

Что гораздо хуже - многократно выросли требования к оперативке при добавлении записей из старой таблицы (обычной) в новую (сегментированную). То есть до такой степени, что данные добавить невозможно. 2 гига опертивки на компе, всё отдано для mysqld - ему мало. Думаю, что при выборке будет та же проблема.

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

http://dev.mysql.com/doc/refman/5.5/en/partitioning.html перечитал, ответов либо не нашел либо не понял.

странная тишина
1
white_thesis
почему тут никого нет?
О. Проявились.
Странно, что последний пост от 14 года. Словно проблемы у мускуля закончились :)

Кстати, раз пошла такая пьянка, кто-нибудь здесь имеет опыт работы с многосекционными (partition) таблицами?

mysqlbinlog и большой запрос.
Рысь
eking_go
Есть 2 сервера (x64, Mysql 5.1.73-1-log (Debian)), поломалась репликация, нужно вытащить проблемный запрос, но он очень большой :(

[Подробности...]Вот так (на мастере) - не получается:
mysqlbinlog --no-defaults -v --start-position=21153090 --stop-position=21153091 /var/log/mysql/bin.000134

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#141224  4:28:48 server id 2  end_log_pos 106   Start: binlog v 4, server v 5.1.73-1-log created 141224  4:28:48
BINLOG '
0BaaVA8CAAAAZgAAAGoAAAAAAAQANS4xLjczLTEtbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 21153090
#141224  4:37:55 server id 2  end_log_pos 21153118      Intvar
SET INSERT_ID=8006867/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;


На слейве:

# mysql --defaults-file=/etc/mysql/debian.cnf -e " show slave status \G;" | grep Log
              Master_Log_File: bin.000166
          Read_Master_Log_Pos: 6508252
               Relay_Log_File: mysqld-relay-bin.000377
                Relay_Log_Pos: 21153229
        Relay_Master_Log_File: bin.000134
          Exec_Master_Log_Pos: 21153090
              Relay_Log_Space: 3321769837


Как еще можно его получить?

что не так с индексом по TIMESTAMP?
1
white_thesis
главноеCollapse )

подробностиCollapse )

Проверил на другом серваке. Фрюникс, mysql version: 5.1.60

EXPLAIN SELECT *
FROM `a2`
WHERE moment >= '2011-01-01 0:00'
AND moment < '2011-01-05 0:00'

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE a2 range timestamp timestamp 4 NULL 1 Using where

Вполне очевидно, что проблема с ключами - локальная. Либо это косяк настройки мускуля либо бага конкретно этой версии Мускуль/win32 5.5.25

?

Log in