Alexey чет как-то был слух, что MVCC в mssql реализовано через жопу (точнее через tempdb), из-за чего тупой переезд на постгрес таки ускоряет.

речь не про сокрость, а про space amplification. не бывает чудес

ой, сорян, я не правильно прочитал :)

если переезд на постгрес даёт 100x меньший space amplification (а в постгресе с этим ДАЛЕКО не идеально, поверьте), то значит в MSSQL с этим совсем беда. и на это уже давно бы кто-то наступил

Посоны, 600-700 запросов к серверу mysql на select при нормальной архитектуре бд могут укладывать сервак по CPU?

Смотря какие запросы...

если переезд на постгрес даёт 100x меньший space amplification (а в постгресе с этим ДАЛЕКО не идеально, поверьте), то значит в MSSQL с этим совсем беда. и на это уже давно бы кто-то наступил

да это бред (в смысле согласен)

Смотря какие запросы...

В данном случае запросы вида ``select ... IFNULL(их штук двадцать)...IF.... join ....where` @mikhalken

смотря какой джойн

нужен правильный join

EXPLAIN запроса покажи

Сам по себе он быстрый, как можно видеть. Но если их штук 600 накапливается, то все ядра в полке.

я бы посмотрел в сторону table_open_cache, open_files_limit, innodb_open_files

их того что ты скинул вот вообще ничига не понятно

на тему скорости

хотя я не умею в мускуль :)

@MarkEg0rov в профайле можно посмотреть распределение по времени - что запрос делал больше всего

@MarkEg0rov в профайле можно посмотреть распределение по времени - что запрос делал больше всего

Эм, в профайле? Это как?

https://dev.mysql.com/doc/refman/5.5/en/show-profile.html

Эм, в профайле? Это как?

сервис->SQL Server Profiler в SSMS*

https://dev.mysql.com/doc/refman/5.5/en/show-profile.html

ВО, блин! Впервые на такое натыкаюсь. Интересненько

я бы посмотрел в сторону table_open_cache, open_files_limit, innodb_open_files

open_files_limit по умолчанию он по идее должен идти 1024. Запросов 600. Или судя из эксплайна каждый запрос открывает три таблицы => 600*3. Или я неправ?

да, я помню. на facebook какой-то крутой 1С-ник хвастался, что перелил данные из MSSQL в постгрес. и они у него ужались в 100 раз! Сто раз, Карл!

Процентов 80 я даю за то, что этот крутой 1С-ник просто не умеет вычислять размер данных, занимаемый в БД... Либо там, либо там.

я там ещё несколько дивных историй дописал. для полноты картины

Дай почитать, перед сном...

В данном случае запросы вида ``select ... IFNULL(их штук двадцать)...IF.... join ....where` @mikhalken

Понятно. Запросы типа SELECT... Т.е. на чтение. НУ ТАК БЫ СРАЗУ И СКАЗАЛ, ЭТО ЖЕ СОВСЕМ ДРУГОЕ ДЕЛО!

Сам по себе он быстрый, как можно видеть. Но если их штук 600 накапливается, то все ядра в полке.

что значит "все ядра в полке"?

можешь в доке погуглить как тюнится этот параметр

точнее последние два

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

можешь в доке погуглить как тюнится этот параметр

Да, я уже погуглил. Ща смотррю на количество оpened_tables. В каждой из баз, сейчас, когда всё хорошо, их под 200 открыто. А вот в глобальном статусе 30 миллионов. Не совсем могу всосать, откуда 30 лямов набежало

эта стата собирается за весь аптайм

на то и global

Да, я уже погуглил. Ща смотррю на количество оpened_tables. В каждой из баз, сейчас, когда всё хорошо, их под 200 открыто. А вот в глобальном статусе 30 миллионов. Не совсем могу всосать, откуда 30 лямов набежало

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

если там "opening tables" - это твой поциент

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

И это смотреть через профайл.

опачки

процитирую классика

"ОТКЛЮЧИ КВЕРИ КЭШ НАХУЙ"

Классик ща засмущается?

"ОТКЛЮЧИ КВЕРИ КЭШ НАХУЙ"

Это из-за его фрагментации ебаной?

нет, дело не в фрагментации

там по-моему достаточно query_cache_size выкрутить в 0 и всё...

Помню, как натыкался на хорошую статью по кешу этому. Кроме того, что всё с ним неоч, там показывалось, как можно высчитать фрагментацию его. И типо с этим тоже проблема

вот лучшая статья по кэшу этому: https://dom.as/tech/query-cache-tuner/

:DDDDD

А есть плагин?

я поставлю

О, классик пришёл))))

Такс. Получается, что в моей ситуации на CPU кеш этот вляет или он просто тормозит запросы

?

и то и то

надо бы кстати такую статью по adaptive hash index написать

а то Оракл что-то борзеет

Слышал еще, что в 5.6 скуля с эти кешем вроде получше. Или пиздеж?

query chache ОТКЛЮЧАЙ!

"ОТКЛЮЧИ КВЕРИ КЭШ НАХУЙ"

приятно....

Это из-за его фрагментации ебаной?

ЭТО ИЗЗА ТОГО, ЧТО КЭШНАХУЙНЕНУЖЕН! (извините мой французский)

Слышал еще, что в 5.6 скуля с эти кешем вроде получше. Или пиздеж?

Ответь СЕБЕ на один вопрос: если твоё приложение посылать 20 раз ОДИН И ТОТ ЖЕ ЗАПРОС в MySQL, то кто его писал ? И что надо сделать?

ага, щаз

Такс. Получается, что в моей ситуации на CPU кеш этот вляет или он просто тормозит запросы

Пока видно, что просто тормозит запросы. А на что значит "кладёт CPU в полку" ты так и не ответил.

не хватает

Такс. Получается, что в моей ситуации на CPU кеш этот вляет или он просто тормозит запросы

Очень может быть, что ПОСЛЕ отключения кэша тебе сильно не полегчает. Тут уже приходи один такой... Или это ты и приходил ?

Я склонен думать, что с циферками что-то не так, не может это никак не влиять на cpu

у тебя сервер не на святом духе работает всё-таки

Ну, сорта нет, группировок в запросе нет. Жоин, IF, IFNULL и всё. Хз, блин.

Может, когда ему не хватает каких-нибудь table_open_cache, то начинает жрать

эти цифры берутся из getrusage(). ядро linux не обещает точной информации, там всё очень приблизительно и на коротких запросах вполне может оказаться 0

для точной инфы нужно смотреть в performance_schema

для точной инфы нужно смотреть в performance_schema

А там разве есть детальная стата по конкретному запросу?

А там разве есть детальная стата по конкретному запросу?

есть

Можно ли автоматически делать записи в джоин таблице с ассоциацией мэни-ту-мэни? (sqlite)

в плане автоматически? а как БД узнает, что с чем вам надо связать?

Коллеги есть вопрос. Разработчики придумали запрос содержащий критерий ‘text’ like table.column || ‘%’. Убрать его сейчас не получается. Можно ли каким-нибудь индексом его оптимизировать? База - PostgreSQL.

в плане автоматически? а как БД узнает, что с чем вам надо связать?

Ну вот например если есть юзер и коммент и таблица user_comment, это конечно не мэни-ту-мэни, но для примера подойдет. При создании коммента нужно писать обязательно 2 запроса: на создание коммента и на создание записи на связку?

Ну вот например если есть юзер и коммент и таблица user_comment, это конечно не мэни-ту-мэни, но для примера подойдет. При создании коммента нужно писать обязательно 2 запроса: на создание коммента и на создание записи на связку?

Я просто пока не очень шарю, вот учусь пользоваться бд только

Ну вот например если есть юзер и коммент и таблица user_comment, это конечно не мэни-ту-мэни, но для примера подойдет. При создании коммента нужно писать обязательно 2 запроса: на создание коммента и на создание записи на связку?

да, если в таблице комментариев нет юзера

да, если в таблице комментариев нет юзера

У меня сейчас 3 запроса, на селект юзера (проверка существования) и 2 на создание. Можно как-то сделать if или как вообще проверяют другие?

руками так, ORMы некоторые умеют из коробки иногда такие вещи

руками так, ORMы некоторые умеют из коробки иногда такие вещи

понял, спасибо. Ормы не уважаю, по крайней мере пока не разберусь в sql полностью)

Посоны, в в mysql есть гипотетический варик сделать нереплицируемую бд мастером, указать слейв - и подождать пока данные сольются до полного синка?

Или я губу раскатал?

Коллеги есть вопрос. Разработчики придумали запрос содержащий критерий ‘text’ like table.column || ‘%’. Убрать его сейчас не получается. Можно ли каким-нибудь индексом его оптимизировать? База - PostgreSQL.

text — это поле?

text — это поле?

text - это текст.

А поле справа.

Чат, а скажите - возможно ли как-то в postgresql 9,6 воспользоваться индесами так, чтобы счетчик обращений не увеличился?

что за счётчик такой?

Коллеги есть вопрос. Разработчики придумали запрос содержащий критерий ‘text’ like table.column || ‘%’. Убрать его сейчас не получается. Можно ли каким-нибудь индексом его оптимизировать? База - PostgreSQL.

Вроде как нет, по моим представлениям.

встроеный постгресовский pg_stat_all_tables .idx_scan

Видимо, это показаны таблицы с записями...

это индексы в таблице, не могу понять именно разрывы что значит

аа понял

разрывы это указатель с узловой страницы предыдущего уровня