Бессмысленный индекс дающий очень малую селективность

Ребят тут можно же задавать тупые вопросы по индексам в mysql?

Вопросы задавать можно, но без ответов.

Всем привет! Накидайте, пожалуйста, ссылок, которые могут на пальцах объяснить как работает оптимизатор Oracle и как использовать хинты

Бессмысленный индекс дающий очень малую селективность

И при таком большом количестве получаемых записей, даже хороший индекс может не быть задействованным

Всем привет! Накидайте, пожалуйста, ссылок, которые могут на пальцах объяснить как работает оптимизатор Oracle и как использовать хинты

http://www.sql.ru/

Может стоит разобраться как индексы работают

а можно ссылку на хорошие статьи? прочитал в хайлоаде, вроде понятно, хотел посмотреть разницу на практике

я тут что-то делаю не правильно? создал индекс по gender для таблицы user_details create index gender user_details(gender) 0.11411000 | select username from user_details where gender='Male' limit 100000 0.24413500 | select username from user_details where gender='Male' limit 100000 без индекса запрос прошел быстрей с индексом обработал на 50% меньше записей но по времени почему-то дольше

КЛАССИКА ПОШЛА! ВОУ!

КЛАССИКА ПОШЛА! ВОУ!

можно по подробней описать мою ошибку?

вроде бы сократил проверку записей на 50%

И при таком большом количестве получаемых записей, даже хороший индекс может не быть задействованным

Индекс эффективен, когда возвращает меньше процента записей в таблице. Перестаёт быть эффективным когда начинает возвращать более 10 % записей. Всё нестрого, всё оценочно.

вроде бы сократил проверку записей на 50%

Это очень мало. Индек должен давать приращение НА НЕСКОЛЬКО ПОРЯДКОВ, в 10-1000 раз.

можно по подробней описать мою ошибку?

эксплейн что говорит? ... может оптимизатор его вообще не задействовал

а можно ссылку на хорошие статьи? прочитал в хайлоаде, вроде понятно, хотел посмотреть разницу на практике

Нет статей. Читай книги.

Дейт, Ульман...

Всем привет! Накидайте, пожалуйста, ссылок, которые могут на пальцах объяснить как работает оптимизатор Oracle и как использовать хинты

В гугле забанили ?

В гугле забанили ?

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

В чате общаются. Решают вопросы. Мне лично с тобой на ЭТУ тему общаться неинтересно и времени нет.

а можно ссылку на хорошие статьи? прочитал в хайлоаде, вроде понятно, хотел посмотреть разницу на практике

Я хз, но есть толковые доклады от Петра Зайцева, Ильи Космодемьянского в сети.

В чате общаются. Решают вопросы. Мне лично с тобой на ЭТУ тему общаться неинтересно и времени нет.

Уважаемый, проигнорируйте и все, кому надо тот напишет, у меня тоже нет желания твое говно читать

Я хз, но есть толковые доклады от Петра Зайцева, Ильи Космодемьянского в сети.

ПО ОРАКЛУ ? ЗАЙЦЕВА?

Нет. У них есть фундаментальные доклады, не зависящие от СУБД

А, ну тогда давай ссылки, если знаешь и не лень.

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

Я лишь хотел сказать, что на сайте оракла в официальной документации в общем очень много написано, и достаточно хорошо.

Ребят как надо высчитать из занятых номеров и количества, свободные номера

Подруге надо помочь

что простите?

Кароч можно ли в скл использовать вычитание

Или как можно это сделать

select 5 - 2;

Спасию

Просто оставлю это здесь #book

А что, хорошая книга? IMHO так шлак...

ну кому то и этого будет достаточно

Лучше Ицика Бен Гана прочитать, не засорять мозг шлаком

Лучше Ицика Бен Гана прочитать, не засорять мозг шлаком

Лучше по этой теме — Мартин Грабер. А эта книжка — только жопу подтереть, да и то жёстко.

на codeby.net была хорошая тема по инекциям

Вторая PDF-ина гораздо полезнее.

MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error. Сервер работает нормально, но в пиковые часы нагрузка повышается и начинаются такие ошибки. В чем проблема и как исправить?

https://stackoverflow.com/questions/19581059/misconf-redis-is-configured-to-save-rdb-snapshots

народ, а здесь есть кто-нибудь кто 1C ERP внедряет?!

есть вопрос по производственному учёту. задачка непростая

Всем доброго времени суток. Есть кто работает с weblogic 11g ? помогите новичку

10 есть, 12 есть, 11 нет

можно ли как нибудь через консоль wlst снимать dump_thread c нод где статус warning ?

хочу как нибудь автоматизирвоать это дело, а то через веб-интерфейс как то долго. К сожалению чата с разрабами я не нашел

Ох это для меня внове. Всегда явно цеплялся debugger'ом если было надо. Впрочем это ещё с 10ки привычка

ребят, скажите когда уместно использовать mongodb?

Когда у данных нет четкой схемы?

Ивенты хранить какие нибудь

Ивенты хранить какие нибудь

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

а есть какие то критерии по оптимизации в выборе?

Допустим я слышал что nosql также надо юзать когда записывать и читать данные нужно очень часто

И то и то часто - это 50 на 50. Это не критерий...

Критерий, надо много писать или надо много читать

И nosql разные бывают, у каждой базы свои плюсы и минусы. С реляционными все более типично...

ERROR: S client not available

И вообще, БД выбирают в которою умеют и под задачу

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

Или это детские нагрузки?

Ну может у тебя там i3 какой-нибудь?

В секунду же?

зависит от запроса и количества ядер =)

утилизировать 1 ядро - 1 запросом запросто… далее смотрите сколько тяжелых запросов прилетает - и вот вам ответ

Ну может у тебя там i3 какой-нибудь?

Сервачек старенький, Dell какой-то на восемь ядер. Но все равно напрягает, что 500-600 запросов в секунду, запросов на селект, которые юзают ключи, могут cpu в полку ставить.

испоьзование ключей - не главная причина разгруза CPU. Смотри сортировки/группировки

MySQL ужасно делает сортировку больших данных. Медленно и с загрузкой всего что только возможно

Всем привет. Может кто-нибудь посоветовать лучшие практики для моего кейса? Есть сервер, который принимает ~1000 хитов в секунду, которые превращаются в 3 шт. INSERT INTO ... ON DUPLICATE KEY UPDATE count = count + 1 Раз в сутки по таблице проходится агрегатор с запросом вида INSERT INTO stat SELECT ... from ... where period between ? and ? GROUP BY user, model_id На innodb нагрузку тянули, в целом было норм, но - место на диске он ел как не в себя и при удалении старых записей требовалось оптимайзить таблицу для реальной очистки места на диске. После перехода на tokudb проблема с диском ушла, но запросы стали объективно медленее работать и памяти на агрегацию уже стало не хватать. Какие варианты лучшие для такого типа нагрузки?

Возможно партиции

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

Всем привет. Может кто-нибудь посоветовать лучшие практики для моего кейса? Есть сервер, который принимает ~1000 хитов в секунду, которые превращаются в 3 шт. INSERT INTO ... ON DUPLICATE KEY UPDATE count = count + 1 Раз в сутки по таблице проходится агрегатор с запросом вида INSERT INTO stat SELECT ... from ... where period between ? and ? GROUP BY user, model_id На innodb нагрузку тянули, в целом было норм, но - место на диске он ел как не в себя и при удалении старых записей требовалось оптимайзить таблицу для реальной очистки места на диске. После перехода на tokudb проблема с диском ушла, но запросы стали объективно медленее работать и памяти на агрегацию уже стало не хватать. Какие варианты лучшие для такого типа нагрузки?

VividCortex для похожей нагрузки использует InnoDB + native partitioning. Только у них нагрузка на шард в 100 раз выше ? https://www.slideshare.net/vividcortex/vividcortex-building-a-timeseries-database-in-mysql

ОТ же они упоролись

Всем привет. Может кто-нибудь посоветовать лучшие практики для моего кейса? Есть сервер, который принимает ~1000 хитов в секунду, которые превращаются в 3 шт. INSERT INTO ... ON DUPLICATE KEY UPDATE count = count + 1 Раз в сутки по таблице проходится агрегатор с запросом вида INSERT INTO stat SELECT ... from ... where period between ? and ? GROUP BY user, model_id На innodb нагрузку тянули, в целом было норм, но - место на диске он ел как не в себя и при удалении старых записей требовалось оптимайзить таблицу для реальной очистки места на диске. После перехода на tokudb проблема с диском ушла, но запросы стали объективно медленее работать и памяти на агрегацию уже стало не хватать. Какие варианты лучшие для такого типа нагрузки?

и не очень понятно, что значит "место на диске он ел как не в себя". purge что ли не справлялся с нагрузкой?

и не очень понятно, что значит "место на диске он ел как не в себя". purge что ли не справлялся с нагрузкой?

скорее всего рост data-free он имел ввиду

ОТ же они упоролись

не нуачо. tokudb тогда совсем сырая была. они и сейчас-то не очень. а myrocks пешком под стол ходил, вместе со всякими кассандрами на пару. да оно и сейчас-то

и не очень понятно, что значит "место на диске он ел как не в себя". purge что ли не справлялся с нагрузкой?

Вопросом занимались админы, просто в сравнении - innodb 30гб на tokudb превратились в 7гб

Вопросом занимались админы, просто в сравнении - innodb 30гб на tokudb превратились в 7гб

разница конечно впечатляющая, но тут подробностей бы побольше. вполне возможно, что сравнивали "раздутую" innodb с плохо настроенным purge-ом против только что залитой tokudb. или tokudb с включенной компрессией. и т.д.

а есть какие то критерии по оптимизации в выборе?

Нет

Возможно партиции

да, пришли к этому же для быстрого TRUNCATE устаревших данных в конкретной партиции и вернемся скорее всего обратно на inno. Я просто надеялся на какую-то серебрянную пулю для моего случая простых, но множества insert. Там, "юзай postgee, будет летать, гарантирую" =)

ты шо

какой постгрес

щас пацаны из монги придут - порвут

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

этому есть объяснение, и так часто и есть.

о да

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