:: Visual Foxpro, Foxpro for DOS
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
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
of63

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
Трафик (количество килобайтов), переданных по сети, можно оценить по Диспетчеру задач, закладка "сеть" - интеграл произведение = время П-образной кривой на скорость сети на процент задействованности макс. скорости. При больших временах передачи вполне можно понять, сколько передано байт, соответствует ли ожидаемому. Фото можно попросить этого экрана Диспетчера при выполнении запроса...
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
spinz

Сообщений: 5263
Дата регистрации: 21.01.2016
Если в виндоусе настроить репликацию удаленных серверов под ssh, то можно найти корреляцию между трафиком и Вопросом №2
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Фото можно попросить этого экрана Диспетчера при выполнении запроса...
Это стоит делать если уже думаешь застрелиться, но это не так



Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 17:20
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
spinz
Если в виндоусе настроить репликацию удаленных серверов под ssh, то можно найти корреляцию между трафиком и Вопросом №2
Мне легче отказаться от Вопроса 2, чем что-то настроить в винде и найти эту корреляцию.



Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 17:24
Ratings: 0 negative/0 positive
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
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
spinz

Сообщений: 5263
Дата регистрации: 21.01.2016
Ydin
Если не смогу, то не расстреляют.
Да и пофиг тогда, верно?

Давайте лучше накатим
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Я уже. У меня по тесту получается, что выиграша по времени нет, скорее маленькое замедление - по всему запросу примерно 0.2 сек
Это воодушевляет!
Т.е. у нормальных будет незаметно.
У тех, у кого подключение к БД через VPN должно улучшиться.
У тех, у кого через модем (вроде их всего двое предприятий) существенно.
Уже такое было.
Я тут вопросы задаю потому что вообще не очень понимаю, чего вообще раньше такое у меня было.
Вроде, с хвостовыми пробелами сам MySql управляется! Но там, где длинная доставка, вроде, не так.
Раньше у нас был доступ к БД заказчика через VPN и я это видел!
Уже в одном месте такую проблему решил 2 года назад.
Недоумеваю - Это по первому вопросу только



Исправлено 4 раз(а). Последнее : Ydin, 03.02.18 18:56
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
of63

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
Сомнение, что трансляция запроса не через локалку, а через интернет "не зипует" передаваемую инфу? По моему не зипует нихсовсем, если не предпринимать спецнастроек. Или вопрос в чем? Медленно отвечает сервер? Причины медленности?
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
По моему не зипует нихсовсем, если не предпринимать спецнастроек.
Вот тут я не только не Копенгаген, а вообще Пномпень. Это такие столицы
2 года назад просто решил не поверить и получилось. Обычно, верю, когда официально пишут.
А потом себе не верю, как сейчас.
Просто тогда мне было легко проверить, а сейчас нет
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
0. А что показывает план запроса?

1. Запрос вынимает все 350 тыс? (Надеюсь что нет, тогда нужен сам запрос)

2. В MySql не силен, поэтому вопрос - есть ли у него полнотекстовый индекс? Ну и др. индексы привести не мешало бы.

3. На худой «конец» можно извернуться через view с материализованными атрибутами, если у сервера есть такие опции.


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)




Исправлено 1 раз(а). Последнее : PaulWist, 03.02.18 20:17
Ratings: 0 negative/0 positive
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)
Ydin
Ведь, если будем передавать больше, чем описано, например, при Char(30) передаем 32, то ошибка и не запишется.
Как раз таки в "строгом" режиме она (ошибка) и произойдёт при попытке записать в таблицу "неподходящие" данные. Это в "старом" режиме тупо и молча урежется строка до размера поля, и запишется.
Ydin
Мое мнение - не нужен нам в Фоксе строгий режим
Это неправильное мнение. То что ты в фоксе при помощи структуры курсора "защищаешься" от ввода слишком больших, или просто "несоответствующих типу" данных - это хорошо. Это просто будет значить что "строгий" режим не будет бить тебя по рукам - конечно же если структуры твоих курсоров "соответствуют" структуре серверных таблиц. Считай что строгий режим - это ограждение между тротуаром и проезжей частью дороги в местах где запрещён переход. Для "дисциплинированных" пешеходов они не проблема, а "хулигана" - ну хоть как-то надо пытаться останавливать
3)
Ydin
Считаю, что нас устраивает MyISAM, а не InnoDB
Опять таки если относится к БД как к помойке - ну да, тут нас*но, тут блеванул кто-то, а вот и они - наши данные, тогда да. Можно забить на целостность. Отсутствие констрейнов и всяких там проверок - из той же оперы. Ну да, будет 100 пустых записей в таблице, или куча дат с 31 февраля - ну ничего страшного же... В конце концов сами разработчики mysql таки ушли от использования myisam движка "по умолчанию".

4) Я не понимаю самой постановки задачи:
- зачем гнать на клиента 350к записей? В 99% случаев это результат неправильного подхода к работе с БД.
- даже если это и "ну абсолютно необходимо" (долбо***м неискореним, особенно в околобухгалтерских кругах), то какая разница насколько быстро они будут извлечены? Если даже предположить что у тебя в 1 записи будет всего одно слово, то 350к слов это примерно 1400 страниц машинописного текста. Ну или, если так понятнее, 3/4 романа "Война и Мир". Сколько требуется времени чтобы это прочитать, или просто распечатать даже на "очень быстром" принтере? Ну и какая разница занимает извлечение 10 секунд или 2 минуты?


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
2 PaulWist
Запрос вынимает все 350 тыс? (Надеюсь что нет, тогда нужен сам запрос)
Да, там стоит select *
Там в форме печати много - я не смотрел подробностей. Тот, (вернее та), кто писал форму, это ее проблема
Там нет Where, это что-то связанное с банками, т.к. имя таблицы vbank.
Там копались до меня. Я даже не глядел, много кода.
Сразу решил сэкономить на том, что другие не делали.
И это мне еще интересно, как типовое.
PaulWist
есть ли у него полнотекстовый индекс?
Нет.
PaulWist
Цитата:
На худой «конец» можно извернуться через view с материализованными атрибутами, если у сервера есть такие опции.
Не смогу, т.к. не знаю, что это такое



Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 20:54
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
2 ИК
Для varchar полей он ни в каком режиме не будет добивать строку до размера поля
Про varchar я даже не подумал!
Он тормозит, где не надо и ускоряет где надо. Я БД не проектировал в MySql. Боюсь сейчас что-то сказать - и не буду
Igor Korolyov
Как раз таки в "строгом" режиме она (ошибка) и произойдёт при попытке записать в таблицу "неподходящие" данные. Это в "старом" режиме тупо и молча урежется строка до размера поля, и запишется.
- знаю
Цитата:
а "хулигана" - ну хоть как-то надо пытаться останавливать
регулируем. У меня объект goSql, у него метод setmode(.t./.f.) - установка строгого режима.
Это чтоб легко было. Там, где надо можно легко поменять.
А никто, почти и не меняет. Но одни включают сразу строгий, другие сразу отключают. На хулигана не нарывались.
И хватит об этом, это уже другая тема
Цитата:
сами разработчики mysql таки ушли от использования myisam движка "по умолчанию"
Это их проблема, я не разработчик движков. У наших свои доводы и в Инете есть еще разные доводы. У тебя мало пока доводов, проедем.
Но информацию мне дал, спасибо!
Цитата:
Я не понимаю самой постановки задачи
А тут и нет постановки задачи. Я постановки и не знаю. Я форму толком не смотрел. Просто видел.
По коду на ее старте (типа в load, у нас это по-другому назывется) проверил, что тормозит. Чтение этой таблицы.
Спросил про список полей и Where - все поля нужны и строки тоже, да и без меня это знают



Исправлено 4 раз(а). Последнее : Ydin, 03.02.18 21:26
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Опана! Where!
Мне сказали, а я поверил! Надо лучше постановку посмотреть...
Вообше дали список больших таблиц, где нет привязки к периоду, предприятию, партнеру (а эта привязка упрощает) - их 3. На этой самый большой тормоз. Я с нее и начал.
Но думал сразу о 3-х.
Игорь, мне уже хорошо, что тему открыл. Я и ждал тебя в первую очередь.
Пашка тоже умно написал. Спасибо!



Исправлено 1 раз(а). Последнее : Ydin, 03.02.18 21:46
Ratings: 0 negative/0 positive
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
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
of63

Сообщений: 25161
Откуда: Н.Новгород
Дата регистрации: 13.02.2008
математику проблемы не выяснил, вот и результ
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Ydin
Автор

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Результ?
В этом dbf то, что у себя, где все на одном компьютере.
Отдельно по каждому полю и запрос со всеми полями.
Это тест, кот. нам надо проверить у нескольких заказчиков.
Это сделают без меня.
По теме мне нужна консультация только.
Задача не моя. Я просто делаю несколько дел в режиме прерывания.
MySql это тоже не мое, но это не значит, что я в нем без понятия. Но и не знаток.
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
spinz

Сообщений: 5263
Дата регистрации: 21.01.2016
Давайте сперва уже накатим
Ratings: 0 negative/0 positive
Re: MySql, строгий режим, быстродействие и др.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Вообще это типичная ситуация - и на форуме постоянно такое происходит. Вместо того чтобы решить проблему кардинально - т.е. дать постановку задачи и спросить как её правильно решать, приводят маленький кусочек из написанного (совершенно очевидно) г*нистого кода, и просят "решить проблему в нём". Бессмысленная и бесперспективная работа.

Просто уже на уровне рефлекса - когда задают вопрос "как мне оптимальнее/быстрее вынуть 100500 записей", первая реакция это "зачем тебе нужно вынимать 100500 записей". Т.к. в 99% случаев этого на самом деле не требуется.


------------------
WBR, Igor
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 24 (Гостей: 24)

© 2000-2024 Fox Club 
Яндекс.Метрика