MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Быстродействие на первом месте.
1. Запрос Select Field1 ... В таблице > 350 000 записей Field1 - CHAR(250), а реально там самое длинное - 29 (это реальная ситуация) Включен строгий режим, поле вычисляемое и теоретически м.б. намного больше. Поэтому так. Ведь, если будем передавать больше, чем описано, например, при Char(30) передаем 32, то ошибка и не запишется. Мохнато как-то! Мне это запрос на Readonly только. Пробую делать так - запрос на MAX(TRIM(Field1)) и получаю Maх длину - запрос на Left(Field1,<полученная длина>) или Cast(Field1 as CHAR(<полученная длина>) Теперь так, - проверяю у себя прям на сервере, где и БД MySql - в среднем, обычный запрос работает дольше, чем запрос с Left, но не всегда - 2 эти запроса работают, в среднем, дольше. 2 прохода ведь - проверяем у заказчика, т.к. у них подключения к БД по сети, VPN и у нескольких (вроде 2 всего) через не новый модем Обе эти статистики меняются существенно в сторону Left Вопрос 1 MySql, вообще, должен как-то паковать все, согласно его опции (сейчас ее не помню, но наш человек по MySql мне ее показал) и на передаче (доставке) я ничего не должен терять во времени. У себя прям на сервере, примерно, так и есть и я бы в это поверил, там разброс есть. Но у юзера, где время доставки существенное, это не так. Почему теряю время? Плохо то, что после атак Юзер отключил от нас свою БД и я не могу повторить свои опыты И не могу здесь привести числа. Сейчас хотели все это смоделировать на своем железе, а я знаю, что это будет не быстро. Вопрос 2 Строгий режим навязал наш сотрудник, кот. свято верит в то, что прочитал в Инет'е Я там тоже читал об этом. Мое мнение - не нужен нам в Фоксе строгий режим: - работая через курсор, при вводе нельзя ввести больше, чем поле ввода для текста позволяет. И мы не влетим "по-строгому режиму". А там, где мы потеряем, то что юзер еще бы хотел ввести, контролируем. Скажем, ввод комментариев - обойдется в 254 символа. Пусть будет лаконичней. Насколько мое мнение правильно выглядит? Вопрос 3 Считаю, что нас устраивает MyISAM, а не InnoDB Нам нужна скорость. Обращения на чтение существенно БД превалируют перед вводом. Исправлено 3 раз(а). Последнее : Ydin, 03.02.18 17:14 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Трафик (количество килобайтов), переданных по сети, можно оценить по Диспетчеру задач, закладка "сеть" -
|
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
Если в виндоусе настроить репликацию удаленных серверов под ssh, то можно найти корреляцию между трафиком и Вопросом №2
|
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 17:20 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Мне легче отказаться от Вопроса 2, чем что-то настроить в винде и найти эту корреляцию. Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 17:24 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Пишу не корректно. Sorry.
Есть форма, не моя. Запускает долго. Основное время - чтение одной из таблиц MySql - 12 cек. Там > 350 000 записей, 19 полей, где в основном текстовые до 250 байт. Это у меня 12 сек. У заказчика много раб. мест. У некоторых не 12 сек., а сколько-то много. У меня задача сократить это время. Если не смогу, то не расстреляют. Как-то без меня смогут запустить у "плохих" тест (prg), кот. я подготовил. И это будет, может, не скоро. Если кто-то сходу что-то подскажет, то это будет здорово. Я MySql знаю плохо или поверхностно и вполне могу расчитывать на то, на Форуме есть те, кто имеют больший опыт, чем я Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 18:28 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
Да и пофиг тогда, верно? Давайте лучше накатим |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Я уже. У меня по тесту получается, что выиграша по времени нет, скорее маленькое замедление - по всему запросу примерно 0.2 сек
Это воодушевляет! Т.е. у нормальных будет незаметно. У тех, у кого подключение к БД через VPN должно улучшиться. У тех, у кого через модем (вроде их всего двое предприятий) существенно. Уже такое было. Я тут вопросы задаю потому что вообще не очень понимаю, чего вообще раньше такое у меня было. Вроде, с хвостовыми пробелами сам MySql управляется! Но там, где длинная доставка, вроде, не так. Раньше у нас был доступ к БД заказчика через VPN и я это видел! Уже в одном месте такую проблему решил 2 года назад. Недоумеваю - Это по первому вопросу только Исправлено 4 раз(а). Последнее : Ydin, 03.02.18 18:56 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Сомнение, что трансляция запроса не через локалку, а через интернет "не зипует" передаваемую инфу? По моему не зипует нихсовсем, если не предпринимать спецнастроек. Или вопрос в чем? Медленно отвечает сервер? Причины медленности?
|
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
2 года назад просто решил не поверить и получилось. Обычно, верю, когда официально пишут. А потом себе не верю, как сейчас. Просто тогда мне было легко проверить, а сейчас нет |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
0. А что показывает план запроса?
1. Запрос вынимает все 350 тыс? (Надеюсь что нет, тогда нужен сам запрос) 2. В MySql не силен, поэтому вопрос - есть ли у него полнотекстовый индекс? Ну и др. индексы привести не мешало бы. 3. На худой «конец» можно извернуться через view с материализованными атрибутами, если у сервера есть такие опции. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 03.02.18 20:17 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
1) MySQL выкидывает хвостовые пробелы из "результатов запросов" по умолчанию. Дополнит CHAR до размера поля он только если специально включить SQL режим PAD_CHAR_TO_FULL_LENGTH - к strict mode этот sql режим не имеет отношения - он про другое. Для varchar полей он ни в каком режиме не будет добивать строку до размера поля. Вообще непонятно почему используется char а не varchar. Сомневаюсь что в сетевом пакете с данными будут "ненужные" байты. Скорее уж там какую-то оптимизацию замутят чтобы даже "невырезанные" хвостовые пробелы не гонять по сети, чем будут для штатного режима (типа всегда применяемого RTRIM) раздувать пакет ненужными байтами.
В любом случае нет особых проблем с тем чтобы замерить объём сетевого трафика для разных вариантов. А заодно посмотреть сколько времени тратится на собственно обработку запроса на стороне сервера. Т.к. вынимать 350к записей - это совершенно очевидно будет не "мгновенной" операцией. 2) Как раз таки в "строгом" режиме она (ошибка) и произойдёт при попытке записать в таблицу "неподходящие" данные. Это в "старом" режиме тупо и молча урежется строка до размера поля, и запишется. Это неправильное мнение. То что ты в фоксе при помощи структуры курсора "защищаешься" от ввода слишком больших, или просто "несоответствующих типу" данных - это хорошо. Это просто будет значить что "строгий" режим не будет бить тебя по рукам - конечно же если структуры твоих курсоров "соответствуют" структуре серверных таблиц. Считай что строгий режим - это ограждение между тротуаром и проезжей частью дороги в местах где запрещён переход. Для "дисциплинированных" пешеходов они не проблема, а "хулигана" - ну хоть как-то надо пытаться останавливать 3) Опять таки если относится к БД как к помойке - ну да, тут нас*но, тут блеванул кто-то, а вот и они - наши данные, тогда да. Можно забить на целостность. Отсутствие констрейнов и всяких там проверок - из той же оперы. Ну да, будет 100 пустых записей в таблице, или куча дат с 31 февраля - ну ничего страшного же... В конце концов сами разработчики mysql таки ушли от использования myisam движка "по умолчанию". 4) Я не понимаю самой постановки задачи: - зачем гнать на клиента 350к записей? В 99% случаев это результат неправильного подхода к работе с БД. - даже если это и "ну абсолютно необходимо" (долбо***м неискореним, особенно в околобухгалтерских кругах), то какая разница насколько быстро они будут извлечены? Если даже предположить что у тебя в 1 записи будет всего одно слово, то 350к слов это примерно 1400 страниц машинописного текста. Ну или, если так понятнее, 3/4 романа "Война и Мир". Сколько требуется времени чтобы это прочитать, или просто распечатать даже на "очень быстром" принтере? Ну и какая разница занимает извлечение 10 секунд или 2 минуты? ------------------ WBR, Igor |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
2 PaulWist
Там в форме печати много - я не смотрел подробностей. Тот, (вернее та), кто писал форму, это ее проблема Там нет Where, это что-то связанное с банками, т.к. имя таблицы vbank. Там копались до меня. Я даже не глядел, много кода. Сразу решил сэкономить на том, что другие не делали. И это мне еще интересно, как типовое. Нет. Не смогу, т.к. не знаю, что это такое Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 20:54 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
2 ИК
Он тормозит, где не надо и ускоряет где надо. Я БД не проектировал в MySql. Боюсь сейчас что-то сказать - и не буду - знаю Цитата:регулируем. У меня объект goSql, у него метод setmode(.t./.f.) - установка строгого режима. Это чтоб легко было. Там, где надо можно легко поменять. А никто, почти и не меняет. Но одни включают сразу строгий, другие сразу отключают. На хулигана не нарывались. И хватит об этом, это уже другая тема Цитата:Это их проблема, я не разработчик движков. У наших свои доводы и в Инете есть еще разные доводы. У тебя мало пока доводов, проедем. Но информацию мне дал, спасибо! Цитата:А тут и нет постановки задачи. Я постановки и не знаю. Я форму толком не смотрел. Просто видел. По коду на ее старте (типа в load, у нас это по-другому назывется) проверил, что тормозит. Чтение этой таблицы. Спросил про список полей и Where - все поля нужны и строки тоже, да и без меня это знают Исправлено 4 раз(а). Последнее : Ydin, 03.02.18 21:26 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Опана! Where!
Мне сказали, а я поверил! Надо лучше постановку посмотреть... Вообше дали список больших таблиц, где нет привязки к периоду, предприятию, партнеру (а эта привязка упрощает) - их 3. На этой самый большой тормоз. Я с нее и начал. Но думал сразу о 3-х. Игорь, мне уже хорошо, что тему открыл. Я и ждал тебя в первую очередь. Пашка тоже умно написал. Спасибо! Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 21:46 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
В январе ускорил запрос типа
select ...,UserProc(Date, typeOfDog) Пользовательская ф-я - вычисление по дате и типу договора - банковскую дату Строк много, а дистинктом по датам, типам - их на порядок меньше... Смотрел по group by, там были каунты 130 и чуть меньше хватало. 20 сек. уехало в 1.8 сек, а коду добавилось 3 строки. А постановку задачи так и не узнал. Исправлено 3 раз(а). Последнее : Ydin, 03.02.18 22:03 |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
математику проблемы не выяснил, вот и результ
|
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Ydin Автор Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Результ?
В этом dbf то, что у себя, где все на одном компьютере. Отдельно по каждому полю и запрос со всеми полями. Это тест, кот. нам надо проверить у нескольких заказчиков. Это сделают без меня. По теме мне нужна консультация только. Задача не моя. Я просто делаю несколько дел в режиме прерывания. MySql это тоже не мое, но это не значит, что я в нем без понятия. Но и не знаток. |
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
Давайте сперва уже накатим
|
Re: MySql, строгий режим, быстродействие и др. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Вообще это типичная ситуация - и на форуме постоянно такое происходит. Вместо того чтобы решить проблему кардинально - т.е. дать постановку задачи и спросить как её правильно решать, приводят маленький кусочек из написанного (совершенно очевидно) г*нистого кода, и просят "решить проблему в нём". Бессмысленная и бесперспективная работа.
Просто уже на уровне рефлекса - когда задают вопрос "как мне оптимальнее/быстрее вынуть 100500 записей", первая реакция это "зачем тебе нужно вынимать 100500 записей". Т.к. в 99% случаев этого на самом деле не требуется. ------------------ WBR, Igor |
© 2000-2024 Fox Club  |