@mysql_ru

Страница 31 из 142
Ruslan
22.06.2017
18:43:32
+-----------------------+ | @@innodb_flush_method | +-----------------------+ | ALL_O_DIRECT | +-----------------------+

Alexey
22.06.2017
18:43:41
какие-то похожие колл-трейсы гуглятся. но никаких конкретных решений, кроме как посмотреть на состояние диска черз smartctl

Ruslan
22.06.2017
18:49:37
У меня на сервере софтовый RAID 1 (mdadm), в зеркале новые Intel® SSD DC S3520 Series 800GB

Еще blkio.throttle.write_bps_device через cgroups на 30 MB/s. Думаю, что он в целом возможно бы мог до него добраться.

Google
Alexey
22.06.2017
18:56:21
вот тут гражданин с чем-то очень похожим: https://github.com/zfsonlinux/zfs/issues/4876

centos 7, софтовый raid 1, правда zfs

говорит, что в итоге всё вылечилось сменой IO планировщика с cfq на deadline или noop

Ruslan
22.06.2017
19:08:01
Планировщик я давно в deadline переключил

Val
23.06.2017
06:36:50
Гайз, утра всем доброго. Кто-нибудь работает в направлении Системный администратор БД (MySQL)? Есть пара вопросов к обладателю столь темной стороной силы. Или тут в основном MySQL проггеры?

Alexander
23.06.2017
07:22:34
ты вопрос озвучь, мож кто и в курсе :)

Val
23.06.2017
07:38:09
Системный администратор БД (MySQL) со ставкой на руки 120-140 на сколько риал. Складывается впечатление что таких специалистов просто нет ? и это больное воображение руководителя найти такого

Антон
23.06.2017
07:52:50
Добрый день! Подскажите, пожалуйста, с запросом

Val
23.06.2017
07:52:53
Антон
23.06.2017
07:53:47


имеется такой запрос, и ошибка, которая ниже гуглил по pass row value to nested subquery, но не нашел рабочего решения

как мне прокинуть туда правильно это значение?

Google
Антон
23.06.2017
08:05:05
есть кто-нибудь?

Dmitry
23.06.2017
09:02:17
наверное дело в алиасе

Антон
23.06.2017
09:03:40
а что именно может быть с ним не так?

Dmitry
23.06.2017
09:04:35
видимо два скалярных подзапроса вложенных друг в друга не дают видеть алиас b

Антон
23.06.2017
09:05:48
Да, что в это примерно дело, я догадываюсь

но не могу понять, как решить такую проблему

Dmitry
23.06.2017
09:06:11
попробуйте заменить на имя таблицы - станет понятно

к какой он может обратиться. а к какой нет

или просто b убрать

Антон
23.06.2017
09:07:37
b заменить на имя, вы имеете ввиду?

сейчас попробую

а, нет, так не выйдет

потому что в подзапросе та же самая таблица

Dmitry
23.06.2017
09:20:26
тогда наверное два подзапроса не видит

если один в другой вложен

lost
23.06.2017
11:47:57
перепишите скалярный подзапрос на обычный подзапрос через join зачем такие трудности

который еще и для каждой строки во в нешней таблице будет высчитываться

Антон
23.06.2017
11:50:02
потому что он не работал

lost
23.06.2017
11:52:23
у тебя одна и та же таблица используется bot_stats: на условия извне добавится еще одно условие по этой таблице внутри скалярного подзапроса почему бы это не использовать в выборке в самом начале или использовать самообъединение таблицы по этому условию

Google
lost
23.06.2017
11:59:00
а чтобы подзапрос увидел алиас b попробуй прокинуть его в первый подзапрос где count,а потом используй его в следующем вложенном подзапросе

Антон
23.06.2017
12:00:19
а как его туда прокинуть?

я нашел только USING

но он не работает

lost
23.06.2017
12:00:57
select count(a.sent), b.datetime

я это имел ввиду

Антон
23.06.2017
12:01:35
тогда подзапрос будет возвращать несколько колонок, это разве будет работать?

lost
23.06.2017
12:02:15
да, ты прав, не будет, об этом я запамятовал

lost
23.06.2017
12:03:17
ща, налячкаю

SELECT a.datetime, COUNT(a.sent) AS cnt FROM ( SELECT DATE(b.datetime) AS datetime, b1.community_id AS id, SUM(b1.sent) AS sent FROM bot_stats b LEFT JOIN bot_stats b1 ON b.id = b1.id AND b1.datetime >= b.datetime - INTERVAL 3 DAY JOIN vk_channels v ON b1.community_id = v.community_id WHERE DATE(b.datetime) BETWEEN ? AND ? AND DATEDIFF(DATE(b1.datetime), FROM_UNIXTIME(v.created_at)) > 7 GROUP BY 2 HAVING sent > 1000 ) AS a GROUP BY 1

чёт типа такого

или можно весь подзапрос с суммой вынести отдельно, и продублировать в него условия DATE(b.datetime) BETWEEN ? AND ? AND а потом приджойнить к таблице bot_stats и посчитать количество

Антон
23.06.2017
12:18:06
Спасибо большое! поробую

lost
23.06.2017
12:18:16
поробуй

Ринат
23.06.2017
14:32:06
Парни

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

вставлять запись если её нет ещё в базе

что то типа нативного insert if not exists есть в mysql?(mariadb)

Fike
23.06.2017
14:34:46
инсертишь, ловишь ошибки констрейнтов

Google
Fike
23.06.2017
14:34:57
есть ошибки = запись уже есть в базе

Roman
23.06.2017
14:35:08
можно посмотреть в сторону https://habrahabr.ru/post/156489/

Ринат
23.06.2017
14:35:32
инсертишь, ловишь ошибки констрейнтов
ну тоесть на стороне серверного языка палить лучше и быстрее?

чем каждый раз селект в базу фигачить?

просто надо будет пройти милллионы записей

Fike
23.06.2017
14:35:59
я ни черта сейчас не понимаю

главное резину не палить

если у тебя одна запись, ты не будешь проходить миллионы записей, индекс сам ее найдет без фуллскана

Ринат
23.06.2017
14:36:40
я ни черта сейчас не понимаю
ну я имею ввиду если средствами бд проверку делать-то перед вставкой надо вставляемое значение попытаться выбрать

Fike
23.06.2017
14:37:03
это все бестолку из-за TOCTOU

Ринат
23.06.2017
14:37:12
ну у меня 300млн записей, из которых в отдельную таблицу сложится наверное несколько тысяч уникальных

Fike
23.06.2017
14:38:27
было бы неплохо услышать задачу полностью, но на самом деле on duplicate key скорее всего самое оптимальное решение, которое позволит не сортировать ошибки по типу

Ринат
23.06.2017
14:38:36
есть лог

хранится в таблице

есть поле-в котором хранится по сути лог nginx - метод, uri, user agent, refferer

все в одной строке. Задача - в отдельную таблицу вынести инфу по user agent. А в новой таблице лога хранить только id шник

тоесть количество комбинаций юзерагентов ограниченно, они будут в отдельной таблице

хз как объяснить. Типа нормализация

Roman
23.06.2017
14:42:00
хз как объяснить. Типа нормализация
https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0

Ринат
23.06.2017
14:44:02
задачу которую нужно решить я описал, суть вроде понятна?

Google
Ринат
23.06.2017
14:45:15
не хранить для каждой строки весь матрац инфы о юзерагенте, вынести в отдельную таблицу. Скорее всего вашей ссылкой на insert for update

Fike
23.06.2017
15:03:34
если задача однократная, то проще всего через select distinct заполнить

если нет, то on duplicate key update, потому что все равно между чтением и записью будет промежуток времени

Roman
23.06.2017
15:05:04
lost
23.06.2017
15:26:54
он наверное хотел спросить как это наживую сделать)

не поломав продакшн

Ринат
23.06.2017
15:31:04
Нет, с продакшна только селект будет

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

lost
23.06.2017
15:34:06
ну тут как бы 300 миллионов записей намекают, что это будет не совсем быстро

Ринат
23.06.2017
15:37:34
Да

lost
23.06.2017
15:37:45
плюс, наверное, ты ещё и ключик захочешь на этот айдишник из отдельной таблицы

Ринат
23.06.2017
15:37:55
Поэтому не хотелось бы неправильным выбором кратно увеличить время

Сначала справочник сформировать

Потом уже шлёпать id

если задача однократная, то проще всего через select distinct заполнить
Я так сделал для другого поля. Но тут то инфа про юзерагент хранится в строке вместе с другими данными

Там ещё из строки надо распарсить нужное

Страница 31 из 142