Size: a a a

2020 May 14

А

Александр in ru_mysql
Этот запрос лучше сразу переписать на update
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
У тебя получается 49к поисков по первичному ключу, сложность каждого log(n), т.е. log(n) * 49к
Надо найти другой индекс которым можно выбрать range сканом, там сложность log(n) + m, т.е. log(n) + 49к
и будет тот же результат, потому что опять будет 49к поисков по первичному ключику
источник

А

Александр in ru_mysql
В любом случае это суммарно будет в разы быстрее, чем сначала выбирать, то что хотим обновить, а потом обновлять
источник

А

Александр in ru_mysql
И по памяти лучше и по ресурсам и по логике
источник

E

Eugene in ru_mysql
не факт
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
В любом случае это суммарно будет в разы быстрее, чем сначала выбирать, то что хотим обновить, а потом обновлять
нет.
источник

А

Александр in ru_mysql
Орм убивает производительность
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
Орм убивает производительность
да
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
Орм убивает производительность
ормы не нужны
источник

MC

Mr. Crestoff in ru_mysql
Александр
И по памяти лучше и по ресурсам и по логике
я попробую
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
нужны сырые запросы
источник

А

Александр in ru_mysql
100%
источник

MC

Mr. Crestoff in ru_mysql
сырым запросом 20 сек, через орм 22 сек
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
Александр
100%
глворим про innodb?
источник

MC

Mr. Crestoff in ru_mysql
есть потери, но не о них речь
источник

MC

Mr. Crestoff in ru_mysql
🇻 🇱 🇦 🇩
глворим про innodb?
верно
источник

А

Александр in ru_mysql
Mr. Crestoff
сырым запросом 20 сек, через орм 22 сек
Покажи что выполняешь
источник

MC

Mr. Crestoff in ru_mysql
источник

E

Eugene in ru_mysql
Александр
В любом случае это суммарно будет в разы быстрее, чем сначала выбирать, то что хотим обновить, а потом обновлять
единственное на чем сэкономишь - на кол-ве переданных данных.
источник

🇻

🇻 🇱 🇦 🇩 in ru_mysql
архитектура говно
источник