{imgicourl}{zamok}
<< предыдущая заметкаследующая заметка >>
07 июня 2020
Вопрос про MySQL часть 2

По советам умных людей перевез базы сайта с MyISAM на InnoDB, написав себе для этого всяких новых кнопок в админке баз движка (которая уже немного по функционалу приближается к PhpMyAdmin :). И немного уже пожалел, что переехал на InnoDB.

Да, проблема инкрементального бэкапа решилась, он стал умнее: /backup 1450M /inc 3701042
Я правда всё равно не очень понимаю, зачем мне прилетели 3,7 мегабайта данных всякий раз, когда в базе не изменилось ровным счетом ничего... Но это уже лучше, чем тупо копировать полтора гига. В любом случае я случайно нашел в коде движка собственный экспорт баз в своем формате (оказывается, я это делал когда-то), чуть подправил его, и теперь думаю делать бэкап баз средствами движка, потому что это точно будет умнее и компактнее. Например, то, что у MariaDB занимает 1450M, у меня в простом формате движка заняло 500M. Но дело не в том, это я как-нибудь сам сделаю, как будет время.

Проблема тут другая. У меня на сервере и раньше подтормаживал MySQL уже не первый год — сайт, как вы наверно не раз наблюдали, подвисает. А с переездом на InnoDB торможение стало таким сильным, что следующие полдня сайт вообще висел, загрузка CPU 400% и всё такое... Когда я поглядываю SHOW PROCESSLIST, вижу такое:


IdUserHostdbCommandTimeStateInfoProgress
18rootlocalhostdnevQuery321Copying to tmp tableSELECT c.`id`,c.`unic`,c.`group`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`0.000
27rootlocalhostdnevQuery314Copying to tmp tableSELECT c.`id`,c.`unic`,c.`group`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`0.000
46rootlocalhostdnevQuery309Copying to tmp tableSELECT c.`id`,c.`unic`,c.`group`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`0.000
76rootlocalhostdnevQuery282Copying to tmp tableSELECT c.`id`,c.`unic`,c.`group`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`0.000
80rootlocalhostNULLQuery0initSHOW PROCESSLIST0.000

Из чего становится понятно, что тормозит вот этот запрос:

SELECT c.`id`,c.`unic`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`golos_plu`,c.`golos_min`,c.`scr`,c.`DateID`,c.`BRO`,c.`IPN`,
u.`capchakarma`,u.`mail`,u.`admin`,u.`openid`,u.`realname`,u.`login`,u.`img`,u.`time_reg`
FROM `dnevnik_comm` AS c
LEFT JOIN `db_unic` AS u
ON c.`unic`=u.`id`
WHERE c.`DateID`='$num'
ORDER BY c.`Time`

Это и правда самый сложный запрос в движке — формирование ленты комментариев, по крайней мере, очень частый. Он берет все комментарии из таблицы комментариев `dnevnik_comm`, относящиеся к номеру заметки $num, добавляет к ним по номеру автора его данные из таблицы посетителей `db_unic` (там этот номер называется `unic`, а тут исторически `id`), причем информации об авторе может не быть у комментариев 15-летней давности, там unic=0 Ну и сортирует по дате комментариев Time.

По индексам — у таблицы посетителей `db_unic` есть primary индекс `id`. У таблицы комментариев `dnevnik_comm` есть индексы PRIMARY `id`, `DateID` (`DateID`), `poset` (`unic`,`scr`) и `Parent` (`Parent`), который к нашей задаче сейчас не относится.

Вопрос специалистам: в этом моем запросе что-то не так? Его можно как-то оптимизировать? Или это нормально, что он выполняется долго и время от времени подвисает на длительное время?

Может, надо добавить индекс для `Time`, а иначе он ORDER BY `Time` не может толком сделать для результата (результаты-то выборки комментариев к одной заметке обычно не слишком велики)?

Я пока что отключил вывод простыни комментариев под заметками, чтобы этот запрос хотя бы выполнялся не для каждого посетителя, а только для тех, кто хочет почитать комментарии, нажав соответствующую кнопку.

UPD: Ого, обнаружил сейчас в движке еще один запрос, начинающийся с тех же букв, только еще сложнее — он работает по адресу /comm и показывает ленту новых комметариев:

SELECT c.`id`,c.`unic`,c.`group`,c.`Name`,c.`Text`,c.`Parent`,c.`Time`,c.`whois`,c.`rul`,c.`ans`,c.`IPN`,
c.`golos_plu`,c.`golos_min`,c.`scr`,c.`DateID`,c.`BRO`,
u.`capchakarma`,u.`mail`,u.`admin`,
u.`realname`,u.`login`,u.`openid`,u.`img`,
«.($GLOBALS['admin']?»z.Access,z.num,»:'').»
z.`opt`,z.Access,z.`Date`,z.`DateDate`,z.`Header`,z.`view_counter`
FROM `dnevnik_comm` AS c
JOIN `dnevnik_zapisi` AS z
ON c.`DateID`=z.`num` " .(empty($acn)?'':" AND z.`acn`='$acn'"). "
LEFT JOIN «.$GLOBALS['db_unic'].» AS u ON c.`unic`=u.`id`
WHERE "
.($GLOBALS['admin']?»1":«z.`Access`='all' AND (c.`scr`='0' OR c.`unic`='«.$GLOBALS['unic'].»')")
.($mode=='one'?» AND c.`unic`='«.e($_GET['unic']).»'":"")
.» AND «.($ncom!='-'?»c.`Time`>'«.$lastcom.»' ORDER BY c.`Time`":«c.`Time`<'".$lastcom."' ORDER BY c.`Time` DESC")." LIMIT ".($lim+1)

Я не думаю, что кто-то пользуется лентой /comm Там 50 посетителей за все время было1, поэтому запрос редкий, и вряд-ли проблема в нем. Так навскидку-то он выглядит сильно ужаснее, потому что объединяет базу комментариев, посетителей и еще базу самих заметок `dnevnik_zapisi` (индексы для z.`Access`, z.`acn` и z.`num` в ней есть). Также, я гляжу, там используются из базы комментариев c.`scr` и c.`unic`, но у меня для этого там их общий индекс `poset` (`unic`,`scr`), вот только не уверен, что в запросе типа AND c.`scr`=0 OR c.`unic`=1 этот объединенный индекс чем-то поможет, наверно надо дополнительно продублировать его последнюю часть `scr`?

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
Страницы, которые привлекли мое внимание за последние дни, рекомендую:
архив ссылок
Оставить комментарий
Windows Safari Chrome
 Mt Laurel
0
0
Alek
Конечно надо. Если индекса нет, будет делать полный скан таблицы, группировать, и проч. Хотя, учитывая, что результат только включает определённыю дату, может и ничего. Я бы сделал отдельный индекс на дату и дополнительный на время. Не поможет, всегда сможете индекс удалить.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Понял, спасибо, для c.Time сделаю индекс.

А дату - вы имеете в виду с.DateID? Это не дата, это порядковый номер заметки в базе заметок - каждый комментарий принадлежит какой-то заметке. (не спрашивайте про имена полей, это очень древние обозначения, за 20 лет многие из них сильно поменяли свой смысл). Для DateID индекс есть отдельный.
Windows Safari Chrome
 Mt Laurel
0
0
Alek
Ну, да, c.DateID. Если отдельны индекс есть, то хорошо. Я думал, это часть primary key.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
В общем, спасибо, я добавил индекс для Time, видимо, в нем и было дело.
Я почему-то думал, что результатов запроса получается сотня и сортировать он их будет все равно без индекса...
Добавил и еще парочку индексов, которые спрашивались редко, но все-таки спрашивались.

Попробую снова включить простыню комментариев под заметками, посмотрим, что будет.

Как-то мне раньше удавалось посмотреть лог самых долгих запросов, но совершенно забыл, где это смотрится в MySQL...
Mac Safari
 Emirates Integrated Telecommunications
0
0
mysql
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
В конфиге
slow_query_log = 1;
slow_query_log_file = /var/log/lleo_slow.log; #любой файл

В май-сиквел можно выбирать куда это дело писать. Само собой, ротацию логов никто на 100% не гарантирует, и надо не забыть отключить через денёк лог, и не логаться если free space на исходе. Или ротировать простым shell-скриптом по cron.
Mac Safari
 Санкт-Петербург
0
0
TI_Eugene
Вообще говоря индекс стоит добавить ко всем полям, по которым хоть как-нибудь, хоть когда-нибудь делается поиск или фильтр или сортировка.
Linux Safari Chrome
 Москва
0
0
LLeo
Про поиск понятно, я был не в курсе что сортировке результата нужно что-то, кроме самого результата.
Windows Firefox
 Нидерланды
1
0
thule
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
А explain что говорит?
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Я им пока не очень умею пользоваться ;)
Windows Safari Chrome
 Израиль
0
0
coolwolf0
Вот зря. У MySQL он очень наглядный (в отличие от Оракла).
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
И как?
Windows Firefox
 Нидерланды
0
0
thule
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Прогнать тот же запрос, добавив EXPLAIN в начале. У вас там вроде только DateID из параметров, подставьте какое-нибудь настоящее значение.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Ну там всякий раз разные значения, от этого зависит и время выполнения же...
Windows Firefox
 Нидерланды
0
0
thule
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
По-разному бывает, но часто это не так важно. Просто сделайте это) Подставьте айди от этого поста, например.
Windows Safari Chrome
 Calgary
0
0
Andrei Lapides
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
first select count(*) from first table
then from the second
then check how explain plan looks
then remove second table and all its fields and run something like this:
SELECT c.`id`, i vse drugie fields po povody kotoruh send nachal mne komplajnat
FROM `dnevnik_comm` AS c
see how long this takes - has to be fast
WHERE c.`DateID`='$num'
ORDER BY c.`Time`
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Спасибо, буду думать, хотя не очень понял, как это измерить в реальности.
Windows Safari Chrome
 Израиль
4
1
б
> Я не думаю, что кто-то пользуется лентой /comm

Слегка охуемши... А что, кто-то не пользуется лентой /comm ? Люди реально перечитывают тонны нашего говна комментариев, заглядывая под плюсики в популярных ветках, чтобы увидеть свежие ответы и добавить свои?

НЕ ВЕРЮ!
Linux Ubuntu Firefox
 Санкт-Петербург
1
0
LLeo
Счетчик показывает, что за все годы (или за последние три месяца, я не помню, как часто у меня статистика обнуляется) на страницу заходили 50 человек ;)
Windows Safari Chrome
 Израиль
1
0
б
Здесь одно из двух:
- или счетчик хреново работает
- или у тебя самый фанатичный фан клуб. Таких фанатов не было даже у Айседоры Дункан!

Но знаешь, судя по тому, что "кому" упоминали многие люди, Винни, например, а его в списке нет, то я склоняюсь к первому.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Ну может быть, я недавно чистил базы, и что-то потерлось. Хотя... нет. Счетчик (уже 51) должен быть верный. Насколько я помню, в движке можно из админки почистить журнал посещений старее 90 дней, при этом именные 100 посетителей превратятся в безликие +100 к числу посетителей заметки. Edge /comm у меня в дневнике (не знаю, как у кого) не модуль, а именно заметка, вызывающая одноименный модуль (у нее есть даже свой номер 1963, видимо в тот момент я ее создал). Поэтому у нее есть общее число посещений, и оно равно 51. Возможно, ваш Винни там был 90 дней назад, поэтому в число 51 входит, а в поименном списке не сохранился ;)
Mac Safari Chrome
 Mt Laurel
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Но знаешь, судя по тому, что "кому" упоминали многие люди, Винни,
> например, а его в списке нет, то я склоняюсь к первому.

Все правильно: Винни упоминал комму строго в смысле "никогда не пользовался и пользоваться не буду". :)
Windows Safari Chrome
 Израиль
1
0
б
В моей реальности это было так:


Mac Safari
 Израиль
3
0
braintunic
> В моей реальности это было так

И ради такой ерунды вы используете вашу редчайшую способность изменять окружающую реальность??
Windows Safari Chrome
 Израиль
1
0
б
Интересно, это только в израильской культуре есть популярная фраза?

- Почему кот лижет свои яйца?
- Потому, что может.
Windows Safari Chrome
 Израиль
1
0
б
Если бы я действительно мог изменять окружающую реальность, то я бы первым делом перезалил вашу иконку. Чтобы она стала квадратной, как любит Леонид. И чтобы мы снова видели её во всей красе.
Windows Firefox
 Израиль
2
0
braintunic
> Если бы я действительно мог изменять окружающую реальность, то я бы

Шайтан!
Windows Safari Chrome
 Израиль
6
0
б
Спасибо. Я хотел еще заказать отмену масок. Но подумал, что это уж чересчур сильное колдунство.

И еще я утешился мыслью, что эпидемия коронавируса, а не спида. А то Леонид нам бы всем презервативы нацепил.
Mac Safari Chrome
 Mt Laurel
2
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> И еще я утешился мыслью, что эпидемия коронавируса, а не спида. А
> то Леонид нам бы всем презервативы нацепил.

Я хочу думать, что у большинства из нас лица и характеры, которые естественным образом защищают от СПИДа.
Mac Safari Chrome
 Mt Laurel
2
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Счетчик показывает, что за все годы (или за последние три
> месяца, я не помню, как часто у меня статистика
> обнуляется) на страницу заходили 50 человек ;)

Ебать ты статистик
Mac Safari
 Израиль
4
0
braintunic
> охуемши... А что, кто-то НЕ пользуется лентой /comm ? Люди реально перечитывают тонны нашего говна ...
> НЕ ВЕРЮ!

А я вот вполне готов поверить, что только 50 человек регулярно пользуются лентой /comm
Это и есть люди, которые бегло просматривают все комменты, один раз, по мере их поступления.

А остальные посетители либо просматривают комменты к заметке один раз в произвольный момент, либо несколько раз пересматривают комменты к заметке (например, раз в день), пытаясь пропустить уже прочитанные ранее и не пропустить ранее нечитанные (“перечитывают тонны нашего говна”), ну либо вообще не читают комменты, разве что иногда, в особо зацепившей заметке.

Но это не так важно.
Важно, что сам LLeo, по его собственному утверждению, пользуется для чтения комментов именно системой /comm !
Поэтому нам, пятидесяти отщепенцам, можно не бояться, что LLeo отключит /comm из-за его неэффективности и непопулярности ;)
Firefox
 Екатеринбург
2
0
Нарик
Спалился человек, дававший эти 50 заходов за три месяца!
Mac Safari Chrome
 Mt Laurel
2
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Поэтому нам, пятидесяти отщепенцам, можно не бояться, что LLeo
> отключит /comm из-за его неэффективности и непопулярности ;)

Ур-ра!

Ну и заодно поздравляю с открытием нового эксклюзивного клуба "50 отщепенцев" вдобавок к уже устоявшемуся клубу "15 старичков-дурачков".
Mac Safari
 Швейцария
0
1
Миха23
Я один раз заходил, наверное, по чьей-то ссылке, и не понимаю в чем там смысл.
Windows Safari Chrome
 Израиль
3
0
б
> не понимаю в чем там смысл

Если пролистать один раз до конца, то при следующем заходе с этого компьютера будут показывать только свежие комментарии
Плюсы:
+ Видишь только свежие комментарии, даже если кто-то прокоментировал заметку пятилетней давности
+ Нет поднадоевших масок, что помогает по аватарке делать первичный отбор читать/не читать/читать внимательно

Минусы:
- Вырванные из контекста ленты сообщения не всегда бывают поняты правильно
- невольно начинаешь тоже комментировать. Затягивает

PS. Комментатора из комы обычно выдает привычка цитировать фрагменты отвечаемого текста.
Mac Safari Chrome
 Mt Laurel
1
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> PS. Комментатора из комы обычно выдает привычка цитировать
> фрагменты отвечаемого текста.

Хааа - точно! Причем, зачастую - для себя, ибо когда дойдешь до собственного ответа, уже забываешь, о чем был вопрос. :)
Mac Safari Chrome
 Mt Laurel
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Слегка охуемши... А что, кто-то не пользуется лентой /comm ? Люди
> реально перечитывают тонны нашего говна комментариев, заглядывая под
> плюсики в популярных ветках, чтобы увидеть свежие ответы и добавить
> свои?
>
> НЕ ВЕРЮ!

Вот и я также всегда думал, как узнал про комму. А оказалось, что даже старички-дурачки, и те не все пользуются. Как дальше жить? :)

P.S. В комме, кстати, нет никакого короновируса! ;)
Windows Firefox
 Австралия
0
0
Andrej Kudriavcev
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Во первых почему left join? Если в `dnevnik_comm` нет записей с `unic` = NULL или с `unic` которых нет в `db_unic`, то лучше просто join, он в разы быстрее. Во вторых поставьте интдексы на `dnevnik_comm`. `unic` и `db_unic`.`id`, если их еще там нет. В третьих, если это большая таблица с записями, которые потом выводятся постранично, то имеет смысл брать только минимум колонок, нужных для постраничного вывода, а остальные данные подгружать отдельным запросом, только для текщей страницы. Идея в том, чтобы сам запрос помещался в память компьютера, тогда он будет быстрым (и его можно кэшировать, так что повторные запросы будут еще быстрее). Если вы берете за раз слишком много данных и у вас в добавок еще и join, MySQL будет создавать для этого запроса временную таблицу, которая будет писаться на диск, и с очевидным падением в скорости.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
1. Я же говорил, естественно в `dnevnik_comm` есть записи с `unic` = 0. Комментарии появились в 2001 году, когда никаких данных, кроме имени автора не существовало, имя прописывалось в поле Name базы комментариев. База логинов возникла году в 2007-2008, поэтому все комментарии до этого года идут с unic=0.

2. Индекс на `dnevnik_comm`.`unic` имеется. Правда это индекс сдвоенный (`unic`,`scr`), но unic там первый, поэтому найдёт его всегда. ИНдекс `db_unic`.`id` конечно есть, это primary.

3. Это крайне редкая ситуация, когда комментариев так много, что они выводятся постранично. Обычно к заметке число комментариев почти никогда не превышает 500, так что морочиться с постраничными запросами нет никакого смысла.

Что касается кэширования запросов, этим у меня почти для всех запросов занимаются внутренние процедуры memcache в движке, а некоторые части (например, уже собранные страницы) я еще и кэширую отдельно. То есть, у меня все равно быстрое кэширование средствами движка и memcache, по статистике около 60% всех запросов идут сразу из кэша, без обращения к MySQL.
Windows Firefox
 Австралия
0
0
Andrej Kudriavcev
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Как вариант, можно создать запись в Unic с ID=0 и опять-таки отказаться от left join. Можно попробовать создать отдельный индекс только на unic и посмотреть, не даст ли это прироста в скорости (всегда можно убрать если толку не будет). Еще вариант, сначала вытащить данные из dnevnik_comm, а потом по мере необходимости загружать строки из db_unic по одной и записывать в какой-нибудь array для последующего использования, т.е. чтобы на странцу каждая запись загружалась не более одного раза. Хотя это звучит противоестествнно и даже глупо, тем не менее такой подход может работать гораздо быстрее join если самих unic'ов на страницу не так уж и много.

Цель всегда та-же самая, отказаться от left join, и по возможности не давать MySQL скидывать данные в файлы, что он делает практически всегда, если есть большая таблица с join и сортировкой.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Я понял вас, спасибо.
Буду думать, как заменить LEFT JOIN на JOIN, хотя совершенно не понимаю физический смысл - почему такая большая проблема для MySQL. Ведь по сути я прошу MySQL всего лишь подавить вопли об ошибке, если дополнительных данных не нашлось. Почему это ей так сложно?

Unic=0 я думал сделать, но мне очень не хочется это делать: 0 в движке означает незарегистрированного посетителя (либо мою ошибку во время разработки новых функций, когда какие-то данные не передались), и черт его знает, какие могут возникнуть неприятные ситуации, если движок не будет орать про ошибку, что unic=0 не найден, и ужас-ужас...

А вот идея подгружать db_unic построчно действительно неплоха - особенно учитывая, что у меня в движке memcache, который позволяет такие штуки держать в памяти довольно долго не только для страницы, но и вообще для всего сервера. Вот только что будут делать бедолаги с этими движком, если у них на хостинге нет memcache...
Windows Firefox
 Австралия
0
0
Andrej Kudriavcev
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Даже без memcache загрузка одной строчки по ID в MySQL займет тысячную долю секунды, это нагрузит сервер гораздо меньше, чем left join, кроме того у MySQL есть и собственный кэш. В моих проектах есть страницы, где в MySQL отправляются тысячи подобных запросов на каждую страницу и все равно время генерации получается сильно меньше секунды. Разница между inner join и left join в MySQL огромна, он так сделан что это всегда было и будет проблемой, особенно если после связки данные надо отсортировать, он просто начинает создавать временную таблицу на диске и общая скорость мигом падает до скорости записи на диск, этого надо избегать любыми способами.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Спасибо, понял, буду думать.

Что забавно: ведь изначально у меня и были построчные запросы. Но потом я "поумнел" и их "оптимизировал" ;)
Windows Firefox
 Австралия
0
0
Andrej Kudriavcev
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Вообще для оптимизации я себе сделал хак, который если сайт крутится на localhost и в режиме debug, выводит мне под футером список всех выполненых запросов и время их выполнения, по этому, если страница тормозит, я могу всегда найти самые длинные запросы, закинуть их в phpmyadmin и поиграться с ними. Очень удобно, правда это для питона.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Хорошая мысль. Не думаю, что мне это будет сложно построить в движке - имея memcache, где я могу хранить такую инфу. Собственно, у меня там и так какие-то сидять в коде следилки, которые пишут "Timeout error"... Мянуточку! Так у меня же это должно быть? А, ну точно!

Нашел: движок пишет зависания (по крайней мере, те, которые все-таки к нему вернулись) в лог.

Там сейчас 8180 строк, и вот что любопытно:

2442 относятся к той самой очень редкой странице /comm, на которую ходит всего 51 человек

543 - зависания на странице /dnevnik/contents (там тоже было очень плохо без индекса Time, как я понимаю).

333 - страницы /dnevnik/rss или /dnevnik/rss.xml

1110 - проблемный запрос /dnevnik/ajax/protocol.php, это чисто админская фишка, глюки постинга на фейсбук.

Оставшиеся 3753 строки равномерно рассыпаны по страницам...

Чудеса чудные. Оказывается, статистика велась. Пойду для начала в RSS залезу. Ага, ну там видимо тормозило из-за отсутствия индекса visible в заметках, я его тоже сегодня уже создал.
Linux Ubuntu Firefox
 Elisa Oyj
0
0
Andor
> MySQL есть и собственный кэш

> The query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

Оракль заявили, что кеш это сложно и выпилили его из мускуля. Если кеш запросов всё-таки хочется, то есть proxysql.
Linux Ubuntu Firefox
 Киев
1
0
Lintruder_0
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
чтобы не путать отладочный 0 с пустым юзером можно сделать синтетического юзера "Коллективный Юзер" с id=-1, и потом проапдейтить все прошлые записи у которых дата старше той, с которой точно стали присутствовать юзер id, на -1
Что-то вроде такого:
«UPDATE `dnevnik_comm` SET `unic`=-1
WHERE `DateID` < Date_When_Started_Appearing_User_IDs AND `unic` IS NULL;
-- и не забыть зафиксировать транзакцию:
COMMIT;»

Тут надо оговориться, что у DateID должен быть или тип даты, или тип целого числа, в виде YYYYMMDD иначе возможны проблемы со сравнением таких значений.

Ну и можно найти минимум максимум дат сначала c отсутствующим юзером, чтоб точно не навредить апдейтом:
«SELECT min(`DateID`),max(`DateID`) from `dnevnik_comm` where `unic` IS NULL;»
если минимум и максимум менше сакральной даты Date_When_Started_Appearing_User_IDs, можно смело(немного поразмыслив, конечно) добавлять коллективного юзера, апдейтить и переходить на обычный(AKA INNER) JOIN
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Вы предлагаете перевести int из unsigned в signed и вдвое урезать диапазон данных?

А что касается DateID, никакого отношения к дате оно не имеет, это просто порядковый номер. Название свое оно наследует от времен 20-летней давности, когда уникальным именем заметки считалась его дата Date, записная строкой char вида "2000-12-26". Позже появился уникальный номер для каждой заметки, он был и назван DateID, то есть ID для каждой Date. За 20 лет многое изменилось, уже и Date не дата, и вместо "2000-12-26" пишется другой формат "2020/06/08", да и вообще можно писать писать любые слова для url заметки, хоть "archive/ESP-files/catalog/index.htm", а уникальный номер autoincrement сохранил свое название DateID.
Firefox
 Киев
1
0
LintruderX
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Не обязательно урезать. Можно взять в качестве "magic value" максимально возможный integer из имеющегося диапазона, например, вместо -1.
Тогда и диапазон цел, и join можно применять.
Автоинкремент в DateID тоже подойдет, т.к для того Update запроса главное, чтоб DateID старших заметок были меньше новых.
Windows Opera
 Москва
0
0
Konstantin Vlasov
> 2. Индекс на `dnevnik_comm`.`unic` имеется. Правда это индекс сдвоенный (`unic`,`scr`), но unic там первый, поэтому найдёт его всегда. ИНдекс `db_unic`.`id` конечно есть, это primary.

Могу ошибаться (я с базами работал мало и давно), но насколько я помню, наличие составного индекса никак не индексирует отдельные поля, входящие в него. Там, вроде, конкатенация выполняется, и строится индекс уже по этому суммарному значению, так что искать только одно поле по такому индексу невозможно. Надо заводить отдельный, специально на unic.
Windows Safari Chrome
 Эстония
1
0
Christian Archer
так, но не совсем. конкатенация строится, но всегда можно искать префикс. по индексу a,b,c можно искать a и a,b
Windows Opera
 Москва
0
0
Konstantin Vlasov
ОК, спасибо за уточнение. Не знал, что индекс позволяет искать по префиксу.
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Батенька, но у вас же лефт джоины. в серьезных системах все оптимизаторы запросов на таком сразу отключаются. попробуйте поиграться с размером таблиц тогда.но лучше мзучить эксплейны, может дело совсем в другом
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Ну а что мне делать-то?
У меня есть таблица А, в которой некие номера.
По этим номерам надо из таблицы B подсосать дополнительные данные, но их там может не быть.
Как иначе сделать, чтоб не было ошибки?

Отсутствовать данные могут по причине, что комментарий написан в первые 10 лет существования движка, когда логина (и базы авторизации) не существовало на сайте, в таких комментариях имя автора подсвечивается серым цветом и дополнительной информации по нему нет, пример заметки с такими комментариями: http://lleo.me/dnevnik/2002/02/11

Также для отдельных комментариев теоретически могут отсутствовать данные по автору номер 1234 - из-за какого-то сбоя, или из-за того, что авторизация 1234 была удалена самим автором или я его забанил за спам, а сам спам остался... Скажу честно, я такого не встречал, но допускаю, что это может быть.

В этих случаях, когда данные подсосать не удалось, движок не должен выкидывать окно с воплями, что MySQL-запрос вернулся с ошибкой, поэтому никакие комментарии к данной заметке отобразить невозможно... :(

Движку 20 лет, таблице комментариев тоже. Таблице авторизации 10-12 лет. Всякая рассинхронизация могла случиться.

Тогда как поступить?
Windows Firefox
 Австралия
1
0
Andrej Kudriavcev
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Найти все записи у которых нет ID в Unic и заменить их Unic нулями - дело двух минут (можно написать скрипт который будет делать это каждый день по кронтабу, если эта проблема возникает переодически), потом добавить в Unic запись с ID=0 и вуаля, left join больше не нужен
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
У них и так unic=0

Но добавлять нулевой элемент мне очень не хочется: это номер ошибки, в движке было довольно много построено на идее, что когда кто-то или что-то попытается указать регистрационый номер 0, то ответом должен быть немедленный отлуп с ошибкой. Сделать ревизию всего кода за 20 лет на предмет этого дела будет сложно и рискованно.
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
ну не нулями, а каким нить левым "разавторизованным пользователем" с уником равным 2123132. ноль это же для примера было сказано.

И навязывать вам свои стандарты проектирования я считаю неправильным - это же ваш проект, и вы должны всегда помнить что, где, как и почему
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Это блин как-то надо строить систему, которая бы в базу его вносила при установке движка во время создания этой таблицы... Это как-то сложно.
Windows Safari Chrome
 Самара
0
0
FixMySql
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Там наверняка же наполняются какие-то справочники - будет писаться ещё одна запись.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Не, там нечего в таблицах не наполняется само. И даже нет ситуации, когда движок понимает, что это его первая инициализация и надо что-то делать начальное. Он взлетает с места в карьер и работает сразу как под нагрузкой.
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
вот не помню, в мускуле триггеров нету?
Linux Safari Chrome
 Иваново
0
0
Ilya
Индекс `dnevnik_comm` должен быть составной date_time( `DateID`,`Time`)
Тогда не будет временной таблицы для сортировки. Первый ключ в запросе для where, второй сразу для сортировки по time. Если все комментарии последовательно - можно time в запросе заменить на id, т.к. id это primary key и он по умолчанию всегда есть в любом индексе. То есть реально индекс по date для СУБД id,date
Left join mysql отлично обрабатывает. Учитывая то, что джойн по первичному ключу - вообще не заморачивайтесь. Главное чтобы все индексы помещались в оперативку.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Вот тут я не понял. Составной индекс хорош когда запросы идут сразу парные Where A=1 and B=3, тогда индекс (A,B) хорошо работает. Но как он будет работать с сортировкой по B? Думаю, никак.

В другом месте у меня идёт запрос без DateID, просто SELECT WHERE Time < 123456, как он будет работать без отдельного индекса по Time?
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
я тоже не понял) похоже илья не смог выразить свою мысль))))) особенно пассаж про примари кей в индекск)))) и чтобы индексы в памяти умещались))))
Linux Safari Chrome
 Иваново
0
0
Ilya
Про индексы в памяти - это первое, что нужно настроить в СУБД. Если за чтением индекса mysql читает диск - это сразу кратное падение производительности. Они по возможности должны быть в оперативке. Сами данные могут читаться и с диска - это не так страшно. Но если индексы читаются с диска, это очень плохо. Часть будет в Кеше ФС linux, но тут уже линуха будет рулить что и когда будет читаться с диска, а что из кеша ОС
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
С такой постановкой не спорю) Единственно, что следует отметить, что индексы нужно создавать разумно - иначе они ну никак не в память не влезут) да и на диск
Linux Safari Chrome
 Иваново
0
0
Ilya
Если индекс составной, то он использует первое поле для where, второе для order by. Если отдельные индексы, то в explain будет временная таблица и там сортировка по отдельному индексу time
Для запроса, где используется только where time=123 этот индекс использоваться не будет. Надо или два индекса(составной и только time) или смотреть explain для запроса с time и как он его отрабатывает. Может там есть другие условия и выборка по time в итоге маленькая.
Структура хранения индексов в mysql innodb такая, что в индексе ВСЕГДА хранится primary key первым в ключе. Для связи со строками данных. Если нет ключа у таблицы - будет внутренний id строки
Windows Safari Chrome
 Москва
0
0
Excelence
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
В общем случае это совершенно не так, и вы зря Леонида путаете
Linux Safari Chrome
 Иваново
0
0
Ilya
Выполните
EXPAIN SELECT c.`id`,c.`unic`,...
ON c.`unic`=u.`id`
WHERE c.`DateID`='$num'
ORDER BY c.`Ti

И для второго случая с выборкой только по time
EXPLAIN SELECT ...

И будет понятно что там выбирается и как. Профилирование запросов оставим на потом или можно в личке этим заняться.
Mac Firefox
 Киев
0
0
gul
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Помимо explain, который порекомендовали уже много раз, и добавления индексов, посоветую ещё mysqltuner. Он может давать дельные советы.

И я надеюсь, innodb включился в варианте file_per_table.
Linux Ubuntu Firefox
 Владимир
2
0
Adamos
Частый запрос. Комменты к конкретной заметке, авторы комментов.
Дергается не только на свежак, но и на каждую страницу, куда пригулял робот и где комменты год не менялись. Таблицы здоровенные, но каждый раз нужен очень скромный фрагмент из обеих, причем чаще всего - один и тот же.

А нужно ли вообще мучить две немаленькие таблицы джойном, если можно сделать запрос к первой, выбрать из нее ID авторов, сделать второй запрос к таблице авторов - и построить то же самое дерево комментариев с чуть более сложной работой с данными, дав мускулю возможность кэшировать то, что, собственно, и не меняется? Он это неплохо умеет без всяких велосипедов...
Windows Safari Chrome
 Киев
0
0
Кондыбас
Тут уже писали про составные индексы, поэтому уточню:

Мускль/мария в одном запросе используют только по одному индексу на каждую упоминающуюся в запросе таблицу. Если таблица используется в разных клаузах по разным полям - одно для JOIN, другое для WHERE, третье для ORDER BY, или даже в каждой клаузе используется несколько полей, то нужен составной индекс по єтим полям. Иногда некоторые поля можно в индекс не включать, если по другим получается достаточно маленький датасет.

SELECT *
FROM dnevnik_comm AS c
LEFT JOIN db_unic AS u ON c.unic=u.id
WHERE c.DateID='$num'
ORDER BY c.Time


Здесь у dnevnik_comm используются поля unic, DateID и Time, а у таблицы db_unic только поле id. Поэтому для дневник_комм нужен индекс (DateID, unic, Time). Почему именно в таком порядке - поле Time, скорее всего, уникально, потому что комменты редко отправляются в одну и ту же секунду. DateID это, скорее всего, идентификатор дневниковой записи, записей меньше, чем комментариев и комментаторов. Т.е. поле DateID более селективно, чем unic, а unic более селективно, чем Time.

Со вторым запросом чуть сложнее

SELECT *
FROM dnevnik_comm AS c
JOIN dnevnik_zapisi AS z ON c.DateID=z.num AND z.acn='$acn'
LEFT JOIN db_unic AS u ON c.unic=u.id
WHERE z.Access='all'
AND (c.scr='0' OR c.unic='unic')
AND c.`unic`='unic'
AND c.Time > '$lastcom'
ORDER BY c.Time DESC
LIMIT $lim+1


Здесь для dnevnik_zapisi нужен индекс (num, acn, Access) или (acn, num, Access)
Для dnevnik_comm нужен индекс (DateID, unic, scr, Time) или с полями в другом порядке.
А для db_unic достаточно (id) который, походу, является первичным ключом.

Точный порядок полей в индексе сложно угадать, не видя данных, но можно схитрить - создать все возможные индексы, и посмотреть, который выберет движок, он достаточно сообразителен, чтобы почти всегда выбрать наиболее быстрый. На больших базах такой прием не прокатит, а на паре гиг - это вполне себе рабочий трюк.
Windows Safari Chrome
 Иваново
2
0
Ilya
Добавлю еще по поводу составных индексов. MySQL использует поля только слева направо подряд. То есть важен порядок столбцов в индексе и чтобы они все использовались в запросе. Если в запросе только самое последнее поле индекса или начиная со второго - он, в отличие от mssql, например, использоваться не будет. Если индекс по колонкам (поле1, поле2, поле3, поле4) и в условиях поле1=123, поле3=1234, order by поле2 - этот индекс тоже использоваться не будет - нужен индекс поле1, поле3, поле2, поле4. Самая правая часть индекса (поле4) может быть отброшена в запросе, но не левая.
Mac Safari Chrome
 Нижний Новгород
0
0
tartaglia
Вообще говоря, во втором случае с униками бред какой-то в вашем варианте, но ладно. Я лет пять не брал в руки MySQL и лет двадцать — PHP, но все равно страсть как интересно.

z.acn='$acn' в третьей строке — cравнение (как я понял) с константой в JOIN-ON вместо WHERE — это идиома такая, стиль нашего веб-мастера или в этом есть какой-то сермяжный смысл?
Windows Safari Chrome
 Киев
0
0
Кондыбас
Да, проверки с константами можно вынести во WHERE, но оптимизатор движка сделает это сам. В смысле, после трансляции кода план выполнения будет одинаковый хоть так, хоть этак.
Mac Safari Chrome
 Нижний Новгород
0
0
tartaglia
Разумеется, раз это мне очевидно, то и оптимизатору движка тоже, я сам так думал.

Правильно ли я понимаю, что движок поедет по указанной на первом месте таблице dnevnik_comm с указанными ограничениями и в указанном порядке, при этом пытаясь подобрать записи в таблице dnevnik_zapisi? Причем поскольку acn и Access в запросе постоянные, движок может предварительно сделать из dnevnik_zapisi выборку по этим значениям, а потом уже в этой выборке искать num — не следует ли в индексе поместить num на третье место?

Интересно: никто не рассматривает вариант, когда не все делает один сложный запрос MySQL, а некоторые запросы выполняются заранее? Например, юзеров у lleo немного (на FB точно больше), можно их хранить в массиве. Я не понял, что за "acn" — может быть, выборку из dnevnik_zapisi по acn+Access тоже можно сделать отдельно. Тогда основной запрос будет по одной таблице.

В конце концов, PHP — это считается языком программирования, там есть свои приемы обработки данных. Необязательно закладываться на голимый движок MySQL.

В общем, я не все понимаю в ситуации, конечно (мне ни к чему, и не хочу), но вариантов много.

Можно даже рассматривать неуклюжие запросы типа
SELECT * FROM t WHERE a IN (2, 3, 5, 7, 11, 13, тут еще несколько штук);

Движок SQL — работяга, но не грех ему и помочь иногда.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Это не константа, а динамическая переменная, которую движок подставляет в запрос. Номер записи.
Linux Safari Chrome
 Иваново
0
0
Ilya
А какой смысл в этом условии?
AND (c.`scr`='0' OR c.`unic`='«.$GLOBALS['unic'].»')")
.($mode=='one'?» AND c.`unic`='«.e($_GET['unic']).»'":"")
Насколько это вообще актуально для новых комментариев в ленте? Может есть смысл заранее отсечь
ANDc.`unic`!='«.$GLOBALS['unic'].»')" - если я правильно понимаю - это заведомо древние комменты. Индексом они отсекутся легко.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
AND (c.`scr`='0' OR c.`unic`='«.$GLOBALS['unic'].»')")

Это - показывать скрытые комментарии только их автору. $GLOBALS['unic'] - это регистрационный номер человека, для которого исполняется скрипт сейчас.

.($mode=='one'?» AND c.`unic`='«.e($_GET['unic']).»'":"")

А это - показывать комментарии только от выбранного автора. Где используется, не помню (возможно, в опции "показать комментарии" в личной карточке? но попробовал, вроде нет). Но тут фильтровка только комментов от конкретного человека, номер которого явно указывается в GET-запросе пользователем.
Linux Safari Chrome
 Иваново
0
0
Ilya
Может быть тогда scr в цикле php фильтровать. Для mysql такое условие - ад. Это наверняка fullscan. Оставить только отбор по unic.
Это что касается
AND (c.`scr`='0' OR c.`unic`='«.$GLOBALS['unic'].»')"
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
А разве ему не достаточно, что есть индекс на scr?
Windows Safari Chrome
 Иваново
0
0
Ilya
возвращаясь к моему тексту об использовании правой/левой частей индекса у нас есть индекс `poset` (`unic`,`scr`). Запроc говорит либо левая часть индекса равна тому-то, либо правая тому-то. Правую часть индекса использовать отдельно нельзя, а для такой правой подходят все левые части, не подходящие под условие c.`unic`='«.$GLOBALS['unic'], т.е. все остальные. Получаем полное сканирование таблицы в поисках подходящих вариантов, либо данные, отобранные другими условиями помещаем во временную таблицу для дальнейшей выборки. Я бы это условие все же обработал на стороне php, т.к. скрытых комментариев, которые следует показывать автору в выводе будет куда меньше всего остального. Если бы вы нашли реально выполненный медленный запрос и сделали explain - было бы значительно легче провести анализ.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Но я же добавил вчера ещё отдельный индекс scr, разве это не решило проблему?
Windows Safari Chrome
 Иваново
0
0
Ilya
Не думаю что mysql будет его использовать. У scr очень плохая селективность. Скорее будет использовать левую часть `poset` (`unic`,`scr`) чтобы сджойнить по unic и отфильтровать where. Если использовать только индекс scr - будет выборка почти всех записей, которых уже не сджойнить с остальными таблицами, ни отфильтровать по unic.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
А разве ему не достаточно, что есть индекс на scr?
Linux Safari Chrome
 Иваново
1
0
Ilya
Вообще очень советую обратить внимание на эту утилиту. https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-[...]. отсортирует по частоте использования, времени выполнения. Может и нет смысла править те условия, которые раз в месяц используются. А другие визуально более легкие могут читать таблицы целиком раз в секунду и блокировать все.
Mac Safari Chrome
 Нижний Новгород
0
0
tartaglia
Это понятно, я неточно выразился в смысле PHP-кода: во время выполнения SQL-запроса это константа для MySQL.
Windows Safari Chrome
 Москва
0
0
Naeel
TEMP используется скорее всего именно для сортировки по Time, потому что сортировку нужно где-то делать.
Нужно обязательно смотреть, что показывает explain для этого запроса.
Предварительно кажется логичным, что:
- на `dnevnik_comm` нужен индекс по DateID (он есть)
- на `db_unic`— просто необходим по Time
Если таблица большая, то доступ по индексу дешевле, а если таблица меленькая, то наоборот дороже.
Windows Firefox
 Сумы
0
0
Fisher123
ORACLE поставить уже сове.. джентльмены, куда вы меня тянете?...
Windows Safari Chrome
 Киев
0
0
viktorious
Я бы понял предлагали бесплатный PostgreSQL хотя бы, но Oracle?
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Здесь есть нюанс: речь здесь идет НЕ ПРО МОЙ сервер. Речь идет о движке, который установлен у самых разных владельцев на самых разных хостингах и должен работать в любых условиях - на php5 вместо php7, при отсутствующем memcache, и так далее.

Поэтому я могу лишь сделать какие-то необязательные настройки на сервере, которые немного улучшат производительность, либо внести в код движка изменения, которые сработают у всех, причем переезд на новую систему будет сделан одной кнопкой в веб-админке без вмешательства в работу сервера на уровне админа.
Windows Safari Chrome
 New York
0
0
https://facebook.com/100002861379231
СЗОТ, но фигасе у вас по книге обвал!
Linux Safari Chrome
 Москва
0
0
LLeo
Старый скрипт не умеет считать главы.
Linux Safari Chrome
 New York
0
0
никого нет
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Почему-то не удивляет

А еще чисто на подумать: в скольких файлах хранятся таблицы в MyISAM?
В скольких файлах хранятся все таблицы InnoDB?
И как работает mysql с файлами на уровне обращений к системным вызовам ОС?
Не говоря о том как сама ОС работает с файлами, позиционированием внутри них, множественными одновременными обращениями и т.д.
Windows Safari Chrome
 Санкт-Петербург
1
1
resistor
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Хе-хе-хе.

Леонид, хватит уже пользоваться этими старообрядческими технологиями! Ставьте Windows, базу на SQL Server, сайт на IIS, движок портируйте на ASP.NET.

И всё будет прекрасно работать! ;)
Mac Safari Chrome
 Mt Laurel
4
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Леонид, хватит уже пользоваться этими старообрядческими технологиями! > Ставьте Windows, базу на SQL Server, сайт на IIS, движок
> портируйте на ASP.NET.
>
> И всё будет прекрасно работать! ;)

Точно! Пара лет работы двум scrum teams, и все будет работать почти так же хорошо, как сейчас
Mac Safari
 Израиль
3
0
braintunic
> Пара лет работы двум scrum teams, и все будет работать почти так же хорошо, как сейчас

А почему нет?

Ведь если, скажем, Яндекс предложит купить весь Кагановский движок binoniq, допустим, за полтора миллиона долларов наличными плюс акции YNDX, то Леонид, я подозреваю, не откажется?

Ну а после покупки, Яндекс сможет посадить за это дело не две, а двадцать Scrum Teams по семь-восемь человек — и тогда уж перевести всю эту хрень на Windows + SQL Server + IIS + ASP.NET не за два года, а за какие-то два месяца! ;)
Mac Safari Chrome
 Mt Laurel
1
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Ну а почему нет?
>
> Ведь если, предположим, Яндекс предложит Леониду купить у него весь
> его движок binoniq, скажем, за полтора миллиона долларов наличными
> плюс акции YNDX, то Леонид, я подозреваю, не откажется?
>
> А тогда Яндекс сможет посадить за это дело не две Scrum Teams по
> семь-восемь человек, а двадцать команд — и таким образом перевести
> всё это дело на Windows + SQL Server + IIS + ASP.NET не за
> два года, а за какие-то два месяца! ;)

Я - за! Было бы неплохо, если б Ллео на этом заработал. Только моя фантазия имеет одно извращение в этом плане: все как вы, Брейн, сказали, деньги и акции, но и retention clause: Ллео остается на 3 года VP of Engineering заведовать переводом сайта на Enterprise. Вот это будет карма так карма! :)
Mac Safari
 Израиль
1
0
braintunic
> Ллео остается на 3 года VP of Engineering заведовать

Ну что вы, ЛЛео не потянет VP of Engineering!
Вот разве что Chief Scientist ;)
Mac Safari Chrome
 Mt Laurel
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Ну что вы, ЛЛео не потянет VP of Engineering!
> Вот разве что Chief Scientist ;)

Ненене, chief scientist - лицо безответственное, оно к продакшну мало отношения имеет. Говорю из личного опыта. Именно чтоб ему пришлось объяснять толпе инженеров как код писать, они будут писать как хотят, а отвечать ему! :)

P.S. Кого когда волновало, кто там что потянет? Даже поговорка есть, что каждый рано или поздно поднимается в точности до уровня, превышающего на шаг уровень его компетентности. :)
Mac Firefox
 Markham
0
0
Ёкл
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Нет такой поговорки.
Windows Safari Chrome
 Челябинск
2
0
vinny-the-poo
Гена по незнанию так обозвал так называемый Принцип Питера:
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».

Это весьма известное положение, имеющее под собой серьёзную логическую основу. Так штааа — есть.
Windows Safari Chrome
 Домодедово
0
0
id
> Ну а после покупки, Яндекс сможет посадить за это дело не две, а двадцать Scrum Teams по семь-восемь человек — и тогда уж перевести всю эту хрень на Windows

Не сможет. Насколько я слышал, Яндекс "живет и дышит" ubuntu. Там вообще не знают, что это такое за зверь - "винда".

> Ну а после покупки, Яндекс сможет посадить
А вот посадить - сможет, да, если сделка будет именно как написано - за "доллары наличными". У нас валюту (пока еще) можно купить в банке, можно хранить (в банке или в консервной банке) и можно продать банку. Все остальные операции с валютой являются преступлением.

А учитывая, что Яндекс - это в определенной степени Сбербанк, и учитывая что Рамблер - который тоже в определенной степени Сбербанк - сейчас делает по теме nginx... то как бы, обходить бы всех их стороной за десять километров, ибо себе дороже.

В общем, "вредный совет детектед". Да и уровень постов тут в таком случае опустится до уровня Дзена... Нафиг-нафиг!
Linux Ubuntu Firefox
 Владимир
0
0
Adamos
> что Рамблер - который тоже в определенной степени Сбербанк - сейчас делает по теме nginx...

Насколько я слышал, вкратце, он делает следующее: попытался наехать, обломался и продал свои "права" патентному троллю, который теперь пытается наехать на Сысоева уже самостоятельно. Разве не так?
Windows Safari Chrome
 Домодедово
0
0
id
Не совсем так, поскольку у разных юрлиц владелец один и тот же. Если Полуэкт Полуэктович учредит ООО "Рога и Копыта" и ООО "Копыта и Рога", и первое наймет второе решать свои юридические проблемы, это вовсе не значит, что тов. Полуэкт тут ни при чем.
Linux Ubuntu Firefox
 Владимир
0
0
Adamos
Я слышал как раз, что такая диспозиция была на первом этапе, а сейчас начался второй: https://www.opennet.ru/opennews/art.shtml?num=53133
Firefox
 Екатеринбург
0
0
Нарик
>А вот посадить - сможет, да, если сделка будет именно как написано - за "доллары наличными". У нас валюту (пока еще) можно купить в банке, можно хранить (в банке или в консервной банке) и можно продать банку. Все остальные операции с валютой являются преступлением.

Стало быть, рубль-то ни фига не армией обеспечен, а совсем наоборот — внутренними силами (МВД, ФСБ, налоговая).
Firefox
 Екатеринбург
0
0
Нарик
Ну вот. Я тут недавно задумался, не завести ли свой блог на Бинонике, а то сколько ж можно срать в комментариях к чужому. Сначала оказалось, что там бэкапов нет, теперь вообще выясняется, что скоро Яндекс всё купит. (Все мы знаем, что было с Кинопоиском).
Linux Safari Chrome
 New York
1
0
никого нет
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
а этим кто-то еще пользуется?
Windows Safari Chrome
 Москва
0
0
lood73
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Сортировка - всегда тяжёлая операция. Поскольку она используется у Вас для OLTP (типовые массовые запросы к движку в реальном времени), её необходимо оптимизировать, используя индекс.
Индекс, который есть у вас сейчас на таблице dnevnik_comm, скорее всего оптимизирует вставки и обновления.
А Вам нужен индекс для аналитических запросов.

Разберитесь, как работает EXPLAIN PLAN. Это помогает понять, как планировщик СУБД интерпретирует запрос.

Если планировщик тупит, можно прямо указать план запроса через хинты:
https://dev.mysql.com/doc/refman/5.6/en/index-hints.html

CREATE INDEX dnevnik_comm_idx on dnevnik_comm (DateID, Time);


SELECT c.id, c.unic, c.Name, c.Text, c.Parent, c.Time, c.whois, c.rul, c.ans, c.golos_plu, c.golos_min, c.scr, c.DateID, c.BRO, c.IPN,
u.capchakarma, u.mail, u.admin, u.openid, u.realname, u.login, u.img, u.time_reg
FROM dnevnik_comm USE INDEX (dnevnik_comm_idx) AS c
LEFT JOIN db_unic USE INDEX (db_unic_pk) AS u
ON c.unic=u.id
WHERE c.DateID='$num'
ORDER BY c.Time
;

Я не спец по MySQL, всё написанное выше нужно тестировать.
Но эти принципы работают для всех СУБД.
Linux Ubuntu Firefox
 Екатеринбург
0
0
gochaorg
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Если проблема осталась, то у меня есть некоторые соображения что можно поделать с производительностью БД

если интересно - дайте знать (nt.gocha@gmail.com / @gochaorg telegram)
Linux Safari Chrome
 Россия
0
0
LLeo
Конечно интересно!
Linux Ubuntu Firefox
 Екатеринбург
0
0
gochaorg
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Тогда я буду исходить из опыта админ/оптимизации производительности для СУБД Oracle/MSSQL принципы такие же применимы и к mysql, только инструменты отличаются

В руководство возьму вот эту книгу https://vk.com/doc44301783_468791847?hash=e2e0a144c97aa40daa[...]

стратегия по оптимизации производительности СУБД

0) Узнать что за сервер
Версия mysql/os/php/etc...
Потом будет важно знать конфигурацию железа (HDD/Mem/Ethernet/CPU)

1) Собирается статистики производительности СУБД / ОС
По началу достаточно собрать статистику за 1 типичный день (по продолжительности типичного цикла нагрзуки - для бухгалтерии типичный цикл от...до отчетного периода) по характеристикам:
производительность hdd - по iostat
основные группы потребления
SHOW INNODB STATUS
SНOW PROCESSLIST
SHOW GLOBAL SТATUS
SHOW SТATUS
(по этим SHOW xxx) мне самому надо еще освежить память, что там к чему
желательно иметь еще лог запросов со временем, к каким URL было обращение в какую секнду

Собирается все это дела по расписанию (cron) с частотой большой (каждые 1..5..10 сек)

Собирается не все подряд а с определенной целью
а) выявить рабочий профиль нагрузки
б) выявить не нормальное поведение (пики\провалы)

всю это обычно скидывается в какой нибудь текстовый файл, который потом на скриптом обрабатывается и превращает все это удобоваримые графики

----------------
дополнительно можно и следует настроить логгирование медленных запросов

1.1)
https://ruhighload.com/Как включить slow log в mysql?

1.2) Включение Slow Query Log без перезапуска MySQL
https://h1d3.org/posts/vkliuchenie-slow-query-log-bez-pereza[...]

1.3) https://ixnfo.com/slow-query-log-mysql.html

Туда будут попадать "медленные" запросы - те который выполняется дольше определенного времени
там только косяк, что не все запросы будут записаны, а только те что выполняются дольше 1 сек

----------------------------
2) Я видел что уже идентифицирован вроде как сам по себе медленный запрос
по идее если точно известно что он виновник, то тут обычно надо рещит что можно с ним поделать

а) переписать (если есть возможность)
б) понастроить сервер

Для запроса можно сделать следующее
EXPLAIN - это будет план

А можно еще использовать профилирование
https://ruhighload.com/Как использовать show profile в mysql[...]

И только после это стоит решать что делать
могут сказать по навешать на все индексов - но, это плохая практика т.к. сами операции по обслуживанию индексов тоже дорого (инчае говоря - еще не известно что хуже недостаток или избыток индексов)

PS Присылайте информацию о версии mysql/os будем разбираться какие инструменты нужно будет доставит
PPS Извиняюсь за такое кол-во букв
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Спасибо!
Linux Ubuntu Safari Chrome
 Киев
1
0
Pa><0m
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Уже предлагали перейти на PostgreSQL или вообще на KV-storage? первый, нх
Linux Safari Chrome
 Москва
0
0
LLeo
Не у всех пользователей движка есть странные вещи. Я не для себя одного движок строю, нужны решения универсальные для типичного хостинга.
Mac Safari Chrome
 Mt Laurel
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Уже предлагали перейти на PostgreSQL или вообще на KV-storage? первый, нх

Да че только не предлагали уже. Тут важно всегда помнить, что цель Ллео, порой неосознанная, не сделать, а заебаться.
Windows Firefox
 Москва
0
0
Roma
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
А чем в итоге дело закончилось?
Удалось ускорить?
Если нет, то можно ли посмотреть на результат explain для обоих запросов?
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Да, стало сильно лучше!

всего комментариев: 121

<< предыдущая заметка следующая заметка >>