MasterZivвадяа может потому как я поставил 64 раряда , а стояла 32?

Если ты поставил 64, значит у тебя система 64 битная, раз оно поставилось.
А раз так, ставить туда 32 бита -- верх идиотизма...

вадя, я особенно не секу в админских делах, потому что я кодер, программный архитектор и организатор работы программистов, но если Зив говорит правду, то для восстановления научной справедливости, вам стоит провести все ваши замеры на 64-битной сборке той старой версии, которая вам давала 60 секунд на latin, а сейчас стала давать 6 сек на юникоде.

вадя, просто у меня за много лет выработался какой-то внутренний страх, что если на ровном месте скорость программы вырастает в 10-100 раз, то скорее всего, где-то просто закралась ошибка эксперимента. Просто при всем вашем энтузиазме, мне слабо верится, что 5.7. при тех же самых условиях работает быстрее 5.5/5.6. Если бы это было так, то интернет давно бы уже взорвался лавиной статей с заголовками MYSQL 5.7 is 10x FASTER!!!

вадяесть где повторить мои наблюдения?

на 64-битной версии мускула, который у вас дает 60 сек
например, если у вас 60 секунд дает мускул 5.5.3, то поставьте его 64-битную версию на ту же самую тачку, сделайте те же самые настройки, замените латин на юникод и проверьте будет давать 60 секунд или 8 секунд.

вадя64 -5.7.9 - 4-5 сек
32 - 5.6 - 60 сек
я хочу исключить свою субъективность...

Мысль Зива была в том, что

64 -5.7.9 - 4-5 сек
32 - 5.6 - 60 сек
64 - 5.6 - 6 сек

вадяа как узнать битность установленной базы?

в командной строке выполните c ключом --version и в ответе будет маркер битности

вадя, ну, фиг знает короче... главное, что вы поставили 5.7, у вас получилась высокая скорость и это главное, а все остальное - фиг с ним!

вадяLumix,
в общем-то радоваться нечему, установка не debian7 вынуждает почти полностью апгрейдить систему...
так что настоящего использования 5.7.9 ещё ждать и дать....
врядли кто будет боевые сервера так апгрейдить

У нас все боевые проекты вообще работают на 5.0.27 - это релиз осени 2006 года и <censored>, потому что мы все равно пользуемся лишь малюсеньким сабсетом из всех существующих возможностей сервера, и этот сабсет расширять не собираемся по организационным причинам.

Все эти новые плюшки имеют смысл только для хайлоадов, где увеличение эффективности запросов на 20% может сэкономить 10 лямов в месяц, а в наших проектах +/- 30% эффективности вообще всем посрать. Когда что-то начинает тормозить в 5-10 раз, тогда есть смысл разбираться, но каждый раз когда проводили разборки подобных случаев всегда находилось решение как можно на том же самом сабсете сделать все быстрее и проще.

Из свежих примеров.
Был очень жирный и сложный селект * групп, чем-то похожий на формирование списка тем форума из списка сообщений с сортировкой по дате, чтобы самые свежие были сверху. Сам запрос лимитированный на 30-50 позиций, а вот если получать count(*) на этот запрос, то получается очень жирный, а если втыкать SQL_CALC_FOUND_ROWS / found_rows() то получится вообще запрос без индексов.

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

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

Но если пользователю очень приспичит, то он может в стиле детской игры на угадывание чисел вводить номера страниц и методом больше меньше угадать число групп. Открыл 30 страницу там есть элементы. Открыл 80 страницу, там пусто, открыл 60 страницу там есть, открыл 70 страницу там пусто. И так выяснил, что элементы заканчиваются на 63 странице. 630 * 10 = 6300 / 2 = 3150 групп.

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

А то я смотрю иногда какие тут темы создают на форуме 18346767 18352742 и думаю, то ли это люди подневольные работают в каких-то то ли банках, то ли взяли консалтинговый проект какого-то крупного завода, то ли просто это какие-то мазохисты... я когда вижу такие портянки, то у меня все внутри просто сжимается от боли...

У меня нет точной метрики, но по ощущениям у нас в среднем sql запрос занимает 3-4 строчки, а самые длинные строчек 10-12, а тут люди присылают какие-то sql-ные портянки на 3 экрана...

вадяты почитай на форуме mssql - там 5-6 экраном норма

Да, я заходил туда однажды, у меня сжалось очко, я очень быстро свалил от туда, и больше к ним не захожу.

И я глубоко в своем сердце по-черному радуюсь, когда получаю новости типа Stack Overflow переехали с винды на никсы.))))

вадядак такие большие запросы не означают, что это плохо.

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

вадяmssql-щики заставляют делать это всё не сервере и с него получают только готовый результат. они используют возможности сервера под 100%, остальной народ процентов на 20....

мне кажется тут важно разграничивать два понятия:
1) список функциональных возможностей сервера (поверхностная, горизонтальная характеристика)
2) мощность отжима на стандартном сабсете (глубинная, вертикальная характеристика)

например, в 5.7 появилась новая "горизональная" возможность - json поля
не факт, что мы будем её юзать
и от того, что мы её не юзаем, мы сильно ничего не теряем

но совсем другая песня, когда мы не использовали select count(*), а вместо этого выполняли запрос целиком, данные не получали, но брали служебный ответ сколько он выбрал полей. Вот это уже глубинная возможность, которую глупо не использовать

это я к чему клоню

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

поэтому задача руководителя-организатора подобрать такой сабсет инструментов, чтобы система тратила Х, а внешний результат все время был бы выше 2Х, 5Х или даже 10Х. Когда система тратит Х и приносит Х, то получается, что система существует только как вещь в себе, а если система тратит Х, а приносит 0.5Х, тогда она ещё и вредительством занимается

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

c mssql никогда не работал, а на аксессе написал много чего для реальных заказчиков, но это было давно, когда аксесс ещё был Access 97

вадянаписать портянку на php, си, java - это круто , написать на sql в половину меньшую портянку и выполняющую тож самое - это некруто .....

На мой взгляд критерий выбран ошибочно...
круто/некруто - это больше из мира конференций по программированию или иного сборища гиков...

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

1) насколько просто проводить изменения и отладку (скорость создания готового решения задачи заказчика)

2) насколько низко установлен технический порог входа (или говоря проще, насколько это можно поручить джуниорам или вообще аутсорсерам)

1) + 2) = насколько легко перекидывать задачи от одного исполнителя другому и насколько легко все это контроллировать

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

вадяподход и правильный и не правильный...
вместо того чтоб поднимать уровень исполнителей , мы опускаемся до их уровня....
я предпочитаю действовать по принцЫпу - мэдлеэно, мэдленно сойти и всё стадо....

не совсем...
тут речь идет о том, что рядовых солдат в армии гораздо больше чем офицеров
суть принципов организации процесса, о котором я веду речь, заключается в вычленении как можно большего числа как можно более простых операций для поручения их как можно ниже (рядовым)
не все, но объемы такого "делегирования" удается сделать очень большими
либо ВСЕ гении, либо ВСЕ стадо - это ошибочное понимание ситуации

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

не вижу в этом примере вообще никакого реального аргумента переноса бизнес-логики в базу
более того, я даже не вижу признаков хайлоада в вашем примере
даже если у вас в колл-центре было бы 100 или 200 операторов - это все равно смешная нагрузка
тем более по локальной сети
все о чем вы пишите можно замутить на элементарном select/update/insert
распечатка и рисование документов вообще к бд отношения не имеет...

вот кстати, отличный пример
там какой-то чувак новую тему открыл 18354445

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

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

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

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