В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

ru_mysql

730 membersпожаловаться на группу
2020 June 17

А

Александр in ru_mysql
Mb1W@
В целом замедляется  INSERT/UPDATE/DELETE на таблице с внешними ключами:
The performance of updating is more, because for each foreign key, an INSERT/UPDATE/DELETE has to check to see if the constraint is satisfied. That means a primary key lookup to the referenced tables. This impact is measurable, and it is greater if the referenced tables are not in the buffer pool.

По этой причине я стараюсь их не использовать без реальной необходимости.
не знаю насколько сильно замедляется в мускуле, но в Oracle Том Кайт тестировал и там было микроскопическое замедление, поэтому настоятельно советовал всегда их использовать чтобы БД не превратилась в тыкву
источник
18:49пожаловаться#1

А

Александр in ru_mysql
могу найти выдержку из книги
источник
18:49пожаловаться#2

А

Александр in ru_mysql
https://www.rsdn.org/article/db/goodoraapp.xml#EZTAE
www.rsdn.org
Правильный подход к созданию приложений
Глава из книги “Oracle: Эффективное проектирование приложений”
В этой главе будут рассмотрены проблемы, которые часто встречаются при работе с базой данных Oracle. Они касаются проектирования системы, ее разработки, тестирования, внедрения и поддержки. Подобные проблемы встречаются при работе не только с Oracle, но и с любой другой программной системой. Возможно, эта глава меньше всех остальных глав посвящена технической стороне вопроса, но тем не менее она является одной из самых важных в этой книге. Дело в том, что нередко встречаются ошибки, которые по своей природе являются в большей степени ошибками организации процесса работы, нежели техническими ошибками.  

Материал предоставлен издательством "Питер".
источник
18:51пожаловаться#3

А

Александр in ru_mysql
оказывается не микроскопическое, а 10-15%
"На основании этого можно сделать вывод, что ссылочная целостность в базе данных добавляет от 10% до 15% издержек. Это невысокая плата за то, чтобы спокойно спать по ночам, зная, что целостность данных защищена и что был использован самый быстрый способ разработки приложения. И не имеет значения, какое новое приложение будет добавлено в систему, поскольку, столкнувшись с этим правилом, оно не сможет его нарушить. Этот же принцип работает и в больших масштабах."
источник
18:52пожаловаться#4

А

Александр in ru_mysql
в любом случае это очень мало и ВК не стоит пренебрегать, т.к. зачастую в приложении есть гораздо больше резервов для повышения производительности
источник
18:56пожаловаться#5

NI

Nickolay Ihalainen in ru_mysql
если в базе FK, значит создателя схемы не интересовала производительность.
источник
18:57пожаловаться#6

NI

Nickolay Ihalainen in ru_mysql
FK - всё ради правильности данных, любой ценой.
источник
18:58пожаловаться#7

А

Александр in ru_mysql
цена минимальна
источник
19:00пожаловаться#8

А

Александр in ru_mysql
приложение с неправильными данными можно смело на помойку относить
источник
19:02пожаловаться#9

NI

Nickolay Ihalainen in ru_mysql
блокировки, вместо одной таблички обращаемся к нескольким за один запрос, так двух миллионов запросов в секунду не добыть с одного сервера. Я не критикую подход проверок консистентности, на таких базах редко можно увидеть что-то быстрее 10-20 тыс запросов в секунду. Для денег - важно, для K-V дорого.
источник
19:08пожаловаться#10

А

Александр in ru_mysql
ну когда надо грузить миллионы строк с секунду это скорее исключительный и один из случаев использования БД, тут наверное можно и отключить для вставки данных.... но потом то всё равно придётся данные проверять.... так что то на то...
источник
19:13пожаловаться#11

А

Александр in ru_mysql
притом отключить желательно только для этого процесса через FOREIGN_KEY_CHECKS=0
источник
19:15пожаловаться#12

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
притом отключить желательно только для этого процесса через FOREIGN_KEY_CHECKS=0
не могу сходу придумать сценарий в котором приходися писать милион строк в секунду
источник
19:16пожаловаться#13

🇻

🇻 🇱 🇦 🇩 in ru_mysql
в одну базу
источник
19:16пожаловаться#14

А

Александр in ru_mysql
вот и я про то же
источник
19:16пожаловаться#15

А

Александр in ru_mysql
в реальных приложениях любые чеки исключительно полезны и всех проще они реализуются на уровне БД
источник
19:17пожаловаться#16

NI

Nickolay Ihalainen in ru_mysql
миллионы запросов в секунду, это про чтение, на запись это сотни тысяч. Сценарий как у facebook - почти все запросы на чтения идут в memcached, в mysql попадают только запросы на запись (на большой процент), FK в rocksdb они даже не стали реализовывать.
источник
19:25пожаловаться#17

NI

Nickolay Ihalainen in ru_mysql
и FK получается совсем не web-scale, особенно неясно что делать с шардированными базами.
источник
19:26пожаловаться#18

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Nickolay Ihalainen
и FK получается совсем не web-scale, особенно неясно что делать с шардированными базами.
если данных больше чем buffer pool, в буффер пуле я так понимаю в первую очередь хранятся индексы и горячие данные. а дерево pk хранятся в ram?
источник
19:28пожаловаться#19

NI

Nickolay Ihalainen in ru_mysql
нет, innodb знает про clustered index (PK), secondary indexes (всё кроме PK) это такая же штука, как и PK с точки зрения буферпула всё одинаковое: просто страницы на 16KB (или как задать при создании базы). Когда страничка редко используется её вымывает page cleaner из буферпула и не важно PK это или не PK. Итого, если база больше чем буферпул, но меняем мы только те странички, которые помещаются в буферпул, то FK не сделают больше IO (они тоже будут закешированы).
источник
19:48пожаловаться#20