Чтобы добавлять сообщения и комментарии, .

@luarviq:
luarviq

Поганый мускул так и не пофиксил баг с кривой функцией LOAD_FILE(), по крайней мере под centos. Как не грузила BLOB'ы без плясок, так и не грузит. Пришлось побайтово считывать бинарник и отдавать его запросу. И сделал я это, хахаха, (где ты там, вчерашний шеллофоб?) в связке shell+sed+awk опять. Как в старые добрые времена на HP-UX. Буде сей строгий дядя опять недоволен и обзывать меня неласково за ето, пропагандируя ООП как silverbullet, мы положим на его пролетарское ХО наш православно-мусульманско-буржуазный МПХ. По крайней мере, до тех пор, пока он не изучит smalltalk. И не пройдет онлайн-тест по написанию интерфейсов на С++ без использования наследования, на одних лишь темплейтах.
Лучшая БД, с которой я работал — это, безусловно IBM DB/2. Было это в 1999 году. ОС была AS/400. Этот ваш линупс ногтя ее не стоит. Жаль, что умерла.

@segfault:
segfault

habrahabr.ru
А почему некоторые выбирают mysql вместо postgresql? Вроде говорили, что у мускуля репликация лучше, но это не совсем правда, судя по статье. Ещё вспоминается невиданная, якобы, скорость движка InnoDB по сравнению с постгре. В установке и администрировании на локалхосте они одинаковы. Зачем кому-то понадобится испльзовать mysql в новом проекте, например?

@qrilka:
qrilka

вообще кто-нибудь использует не постгрес, а мускул из хаскеля? Надоб не очень сложную базку навернуть, но джойны нужны, хотел esqueleto использовать, но смущает автомагический подход персистента к миграциям БД, а дублировать схему ещё где-то как-то очень не хочется

@netneladno:
netneladno

2016 год заканчивается
flamingspork.com

@tosh:
tosh

Пацаны подвезли версию 8.0
В релизнотах много смешного.

mysqlserverteam.com

@netneladno:
netneladno

mysqlserverteam.com

@netneladno:
netneladno

что нового в mysql 8.0
datacharmer.blogspot.com.by

@netneladno:
netneladno

MySQL 5.7.15 has been released and has one new feature — now you can disable InnoDB deadlock detection. We may have added that feature back in 2009 (when we were still using 5.0) and used it on most of databases ever since.

@Stepper:
Stepper

профилирование запросов
devacademy.ru

@netneladno:
netneladno

InnoDB is a pretty solid and popular key/value store. There are even packages that bundle InnoDB with some SQL front-ends: MySQL and MariaDB are the most popular ones.

@otakuSiD:
otakuSiD

use -B -N switches to cleanup output from ASCII tables and column names


sites.google.com

@netneladno:
netneladno

bugs.mysql.com
короче хуй поюзаешь auth_socket нормально
придется и дальше для локальных дрочить с .my.cnf и паролями

@Evilways:
Evilways

Понадобилось за одним человеком чинить рекапчу. Как следствие, выпилить кучу спамеров из друпала, аж 22.5К. Оказалось относительно просто это замутить. В основном они обитали на одинаковых почтовых доменах,

Складываем в кучки ящики с одинаковыми почтовыми доменами и сортируем по размеру кучек:
MariaDB [asdf]> SELECT substring_index(mail, '@', -1), COUNT(*) AS MyCount from users GROUP BY substring_index(mail, '@', -1) ORDER BY MyCount DESC;

Ну и выпиливаем по имени домена:
MariaDB [asdf]> DELETE FROM users WHERE mail LIKE '%maildin.com';

В принципе можно даже так:
MariaDB [asdf]> DELETE FROM users WHERE mail LIKE '%.gq';

И даже как-нибудь так:
MariaDB [asdf]> DELETE FROM users WHERE mail LIKE '%s.com';

Спамеров на mail.ru и подобных можно выпилить методом исключения. Сначала надо взглянуть на логины:
MariaDB [asdf]> SELECT name FROM users WHERE mail LIKE '%mail.ru';

Записал тех, кто явно не спамер, далее удаляем всех, кроме них(имён было немного больше, сократил):
MariaDB [asdf]> DELETE FROM users WHERE mail LIKE '%mail.ru' AND name != 'ольга' AND name != 'Екатерина92' AND name != 'аня' AND name != 'admin' ;

Вероятно, это всё можно сделать более оптимально. Даже скорее всего, но как всегда времени разбираться не было. Зная реальных пользователей, можно было сразу указать выпилить всех, кроме них. Но всех 22.5К просматривать не вариант, да и реальные люди успели порегаться в процессе, так что по датам кромсать тоже не катит.

@Balancer:
Balancer

Хотите, чтобы COUNT(*) в InnoDB на миллионных таблицах считался мгновенно, а не десяток минут? Добавьте пустой однобайтовый индекс :D — linux.org.ru

@netneladno:
netneladno

нихуясе чо бывает
dev.mysql.com

@netneladno:
netneladno

slideshare.net

@DespicableMe:
DespicableMe

pastebin.com
Зараза не вставляет данные.
Забыл уточнить, что

$tmpStr = "[[[51.652526019120394,39.1798995256424],[51.66555129808148,39.19534904956819],[51.65572930549071,39.2011855363846],[51.652526019120394,39.1798995256424]]]";
Такая строка приводится к нужному и виду и я пытаюсь её вставить.
Рабочий запрос выглядит примерно так: UPDATE `articles`
SET `bcoords`=
GeomFromText('POLYGON(51.65252601912 39.179899525642 , 51.665551298081 39.195349049568 , 51.655729305491 39.201185536385 , 51.65252601912 39.179899525642 )')
WHERE id = 2
Что делать?

@DespicableMe:
DespicableMe

Anybody can help me?
I need store multipolygon from simle json like [[[51.659473623649205,39.201592693957046],[51.65976722246264,39.20219887319441],[51.65913331354108,39.20296598497267],[51.65889309309455,39.202359805735306],[51.659473623649205,39.201592693957046]]]
Yes, it's look like polygon, but in some cases it will be multiple polygon.
So, how I can store it in database using php5? Anybody can give right database query?

@DespicableMe:
DespicableMe

Кто — нибудь знает стандартную функцию приведения json к geojson? Или есть ли у кого своя готовая функция?
Буду признателен :-)

@RA:
RA

Ебатушки-ребятушки
MySQL's utf8 encoding is not actual UTF-8. It's an encoding that is kinda like UTF-8, but only supports a subset of what UTF-8 supports. utf8mb4 is actual UTF-8.
А чтобы перейти с utf8 на utf8mb4 надо сделать 6 шагов
mathiasbynens.be

Но и этого мало. utf8mb4 не умеет fulltext индексы. А значит придётся делать одно поле utf8, а второе utf8mb4.
И это всё надо чтобы хранить в базе смайлики. Скажите мне что я не прав и можно сделать иначе.

@wilful:
wilful

Ок, гугл. При загрузке дампа mysql < sql в базу лочится другая база на том же сервере, с чем то может быть связанно?

@CaufMAN:
CaufMAN

А почему в 99% случаев рассматривается связка похапе именно с мусклом? Чому не постгрес или скулайт? Или это обусловлено какими-то архитектурными решениями и пых в связке с мускулом куда производительнее, недели с др бд?

@OCTAGRAM:
OCTAGRAM

About SphinxSE in MariaDB
Любопытный способ сделать поддержку Sphinx в LAMP проектах. Там ещё и JOIN можно делать.

@Dimez:
Dimez

optimize table table_name;Stage: 1 of 2 'altering table' 550% of stage done

@AlexVK:
AlexVK

Интересная баго-фича mysql.
К чему может привести описано тут desmart.com
Документация по поводу тут dev.mysql.com
Суть: счётчик значения auto_increment находится в памяти и переинициализируется при перезапуске запросом вроде этого SELECT MAX(ai_col) FROM t FOR UPDATE;
Т.е. вставили 300 записей в таблицу с полем int auto_increment , смотрим счётчик — 301, удалили 100 последних записей, перезапустили и счётчик уже 201 — дальнейшие вставки вновь получат id от 201 до 300.
Проверил — так и есть.

@Balancer:
Balancer

В копилку. Есть распространённая ошибка, когда в MySQL дефолтовый с latin1 пишут utf8. После исправления или при выставлении нормального чарсета русский превращается в тыкву типа «Ð”ÐµÐ»Ð¾Ð²Ð°Ñ� Ð�виациÑ�».

Такое преобразование исправляет ошибку средствами самого mysql без всяких дампов/загрузок:

CONVERT(CAST(CONVERT(field USING latin1) AS BINARY) USING utf8)

Т.е. что-то типа:

UPDATE ox_campaigns SET campaignname = CONVERT(CAST(CONVERT(campaignname USING latin1) AS BINARY) USING utf8) WHERE campaignname LIKE '%Ð%';

Последний LIKE — чтобы не перекодировались строки, куда уже после исправления кодировки соединения корректный русский запишется.

@netneladno:
netneladno

bugs.mysql.com
мускуль сбрасывает автоинкремент при рестартре сервера
с 2003 года
сука ад

@netneladno:
netneladno

ресторю дамп уже 16 часов
рестор замедлился и я решил поразбираться почему

лонг стори шорт
запускаю pt-ioprofile
он мне показывает всё что должен и пизда
мускуль висит, не отвечает и нихуя не делает

слава богу SIGSTOP SIGCONT его разбудили

@borman:
borman

Читал исходники mysql.
Какой же это, оказывается, поганый замшелый написанный левой пяткой говнокод :( Там даже табы вперемешку с пробелами.
Ну то есть я слышал, конечно, что там архитектура "не очень".
Но не настолько же, черт возьми.

@thefish:
thefish

slideshare.net

@netneladno:
netneladno

прописали на реплике по всем канонам

relay_log_info_repository = TABLE
relay_log_recovery = ON
sync_binlog=1

получили 400мб/с записи на диск и отстающий слейв

убрали sync_binlog и получили старые добрые 10-20mb/s как на мастере

охуенно

@agr:
agr

facebook.com
Вброс №2.

Поехали.
Причём тут MySQL? — Facebook изначально на нём поднимался (к слову о технологиях).

Oracle, пользуясь случаем, передаю тебе привет.

@OCTAGRAM:
OCTAGRAM

Освоил переключение между MySQL клиентом и командной строкой по Ctrl-Z и fg 1

@netneladno:
netneladno

googlecloudplatform.blogspot.com.by

@Zert:
Zert

А как так случилось, что Забиватор забил на мускуль и стал топить за постгрес? Что произошло?

@OCTAGRAM:
OCTAGRAM

MariaDB Debian Wheezy
Ставлю MySQL на ещё одну тачку. По привычке начал делать apt-get install mysql-server, но тут вспомнил, что после покупки Sun Oracle'ом из–за недружественной к сообществу политики Oracle надо бы переходить на нечто более дружественное, как я уже сделал, перейдя на LibreOffice вместо OpenOffice.org, и в данном случае надо бы ставить вместо MySQL MariaDB, которого, правда, в пакетах не оказалось. Попробовав разные дополнительные deb–репозитории, нашёл рабочий вариант для Debian 7 Wheezy.

@schors:
schors

запутался. есть таблица A с полями id, value, есть таблица B с полями id, value, a_id. B.a_id заявлен как FOREIGN KEY к A.id. мне надо в транзакции залочить два неких ряда из таблицы A и всё что там к ним привязано в таблице B. ничего кроме увесистого SELECT FOR UPDATE LEFT JOIN который потом ещё и софтварно разбирать (или повторять SELECT, но уже потаблично) не придумал

@Balancer:
Balancer

Своеобразное первое крещение огнём. 6 дней назад отвалилась master-master MySQL репликация на вторичный сервер. Посколько он не используется, а я на выходных мотался на свадьбу к родственникам, то заметил это только вчера. Отставание от мастера превышало 400000+ секунд (5 суток), а время хранения бин-логов на сервере — 3 суток. Классическое решение в этом случае — mysqldump (или percona xtrabackup, что не сильно лучше и много сложнее) и возобновление репликации.

Поступил иначе. Возобновил репликацию с начала первого доступного файла бинлога, и провёл синхронизацию проблемных (по целостности внешних ключей) данных через pt-table-sync. Всё решилось онлайн, без простоев :)

@justonemore:
justonemore

Unicode support in MySQL is ... codeka.com.au

@rakoth:
rakoth

А вы знали, что если мускулу сказать:
SELECT * FROM `$TABLENAME` WHERE `$DATETIME_FIELD` LIKE '%ф%';
то свалится запрос с руганью на
#1271 — Illegal mix of collations for operation 'like'
но если без кириллицы:
SELECT * FROM `$TABLENAME` WHERE `$DATETIME_FIELD` LIKE '%w%';
то всё нормально отработает.
Зачем нужно лайкать дейттайм? Спросите у автора DataTables.
А вот как бы выразился слоник на подобную ахинею:
No operator matches the given name and argument type(s). You might need to add explicit type casts.
Оракул, какого хрена?