<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Индексирование не панацея, иногда время на создание индекса увеличивает время выполнения запроса
Это правильно, если условие накладывается на ключевые поля. Если условие накладывается на поле результата (например, СуммаОборот > 100000), то воспользоваться параметром Условие просто невозможно.
Кстати, мало кто знает, что СКД, реализуя отбор, иногда формирует в запросе секцию ГДЕ с условием на измерение виртуальной таблицы… И мы ломаем голову, с чего это отчёт так тормозит.
(2) Конечно, если поле не ключевое, то его не удастся поместить в параметры виртуальной таблицы. Однако некоторые условия с ключевыми полями тоже неправильно помещать туда. Посмотрите упомянутую статью ИТС.
(3) Для СКД последнее время для размещения условий использую предусмотренную конструкцию { …….КАК ПолеОтбора}, с использованием отборов. Это позволяет сделать исполнение более предсказуемым.
Скажем так, на хайлоаде Индексировать рекомендуется не использовать, потому что создание индекса временной таблицы — дополнительная и весьма существенная нагрузка, а самое главное абсолютно бессмысленная, как в этом примере, нагрузка.
В моей практике только на одном запросе индексировать как то увеличило быстродействие, есть примеры, когда эта операция значительно увеличило время выполнения запроса.
Но это ответ уже совсем на другие зарплатные ожидания.
Мне нравятся такие статьи. Но если честно, тем, что они заставляют/побуждают, наконец, открыть профайлер и посмотреть как работает запрос на физическом уровне.
А уж если совсем придиратся, то периодичность — регистратор в таблице оборотов — это по сути дела двойной вложенный запрос в таблицу движений без использований таблиц итогов, в данной ситуации для этого отчета было бы правильнее сделать простейший запрос к реальной таблице, он был бы в данной ситуации оптимальнее. (Просто потому что периодичность регистратор не использует итоги и оптимизатору будет проще подобрать оптимальный план запроса для запроса который не использует вложенные подзапросы).
А это ответ еще на более высокие зарплатные ожидания)
(7) я начинал изучение 1С с просмотра курсов Павла. Спасибо ему.
(6) Есть нормативы по скорости операций SQL. Если количество строк в одной таблице Х, а в другой таблице Y, то например
1. Индексация первой таблицы потребляет времени порядка Х
2. Индексация второй таблицы потребляет времени порядка Y
3. Соединение двух индексированных таблиц потребляет времени порядка (Х+Y)
4. Соединение двух НЕ индексированных таблиц потребляет времени порядка (Х*Y)
о чем я писал
Поэтому почему «на хайлоаде Индексировать рекомендуется не использовать» мне не понятно.
Можете привести источник ?
(10) Устные рекомендации по опыту внедрений больших проектов на семинарах в 1с.
По факту одна из рекомендаций, если это возможно, то и временные таблицы не использовать, потому что их создание — затрата ресурсов, в частности запись в оперативную память, или сразу в темп дб, если она большая, и если за время до сброса она не уничтожится, то сброс в темпДБ..
Индексировать, это по факту создание таблицы с кластерным (в 83) или не кластерным индексом (не 83) в оперативной памяти или темпДБ. А при большой загрузке на это может просто не хватить ресурсов, начнет кончатсся место в памяти, будут постоянные сбросы на диск и тд.
Если таблица маленькая, то затраты на индексирование не окупят выигрыша.
Если большая — то тоже.
В Вашей статье не написано сколько пользователей работало в момент эксперимента. То что будет хорошо работать при одном пользователе, не факт что будет хорошо работать хотя бы при 100 пользователях.
верните меня лет на 10 назад, плюсану оттуда
(11) Рекомендации не использовать индексы и временные таблицы?
Легко проверяется, что эти методы дают отличные возможности по оптимизации. Ускорение в разы при использовании временных таблиц. Главное найти узкое место в запросе.
По поводу индексирования: тоже все давно известно, зависит от типа данных и от возможности разложить эти данные по страницам индекса.
Если это булево: смысла делать индекс нет, а если ссылка и много записей в таблице — однозначно нужно делать.
Без обид, но комментарий теоретика.
Можно получить ссылку на устные рекомендации, очень интересно послушать?
(13) По поводу индексирования больших временных таблиц не может быть никакой однозначной рекомендации, в каждом конкретном случае нужно смотреть планы запроса, чтобы определить, поможет индексирование, или наоборот…
(13) 1) Не использовать временные таблицы, ЕСЛИ ЭТО ВОЗМОЖНО, а не неиспользовать вообще.
2) Не не использовать индексы, а не использовать ключевое слово ИНДЕКСИРОВАТЬ в запросе.
3) У меня сейчас онлайн 250 человек, результаты в тестовой и боевой базе иногда кардинально отличаются. Всего одному запросу из нескольких тысяч помогло использование ключевого слова ИНДЕКСИРОВАТЬ. В остальных случаях изъятие этого компонента из запроса или немного улучшает или значительно улучшает скорость выполнения запроса, и так же после массового изъятия из запросов нагрузка на СУБД снизилась и это уже практика.
4) Так же немало примеров, когда изъятие разбиения на пакеты значительно ускоряло выполнение запроса, но тут же опять есть рекомендация — не больше 5-8 соединений (в зависимости от источника). Опять же чистая практика.
(15) попробуйте добавить индекс на поля, которые далее используются в соединениях.
Иногда важен порядок индексирования во временных таблицах.
Из моей практики: перенос вложенных запросов во временную таблицу с индексированием дал прирост на проведении по партиям (УПП 1.3). Снижение на 40% времени проведения.
По индексированию: т.к. набор данных не статичен, данные меняются со временем, и возможно через пару лет работы все изменится как раз наоборот: индексирование ускорит запрос.
Я предпочитаю проиндексировать данные в запросе.
(16) Ну да, лучше проиндексировать — авось, через 10 лет поможет. Не очень профессиональный подход, на мой взгляд.
(17) однозначно без индексов?
Более профессионально объясните?
(18) Нет, конечно. В каждом конкретном случае индекс либо ускорит запрос, либо нет 🙂
Ну правильно. Запрос с отбором по большому списку работает медленнее, потому что на СУБД он преобразуется в запрос с условием «Table.Field IN (&N1, &N2, …, &Nk)». Представляете, какой длины он будет при k = 10000? В данном случае соединение с временной таблицей по индексному полю будет гораздо шустрее.
Еще по своему опыту заметил, если переписать такой запрос примерно так:
Показать
то его производительность на больших объемах данных возрастет, т.к. оптимизатору СУБД будет проще построить оптимальный план.
И, как уже писали выше, в этом примере периодичность «Регистратор» не позволит использовать таблицу итогов. А это значит, что такой запрос всегда будет обращаться к таблице движений. Поскольку по составу выбираемых полей этого не требуется, здесь правильно поставить периодичность «Период».
(20) Если я не ошибаюсь, то начиная со списков более 256 элементов оптимизатор переносит список в таблицу и делает отбор по соединению, в любом случае неясно что придет в голову оптимизатору и такие ситуации лучше описывать декларативно заранее.
И на сколько я помню таблица итогов начинает использоваться с периода МЕСЯЦ и более
(12) Отличный юмор. Да, я безнадежно устарел )).
(8) Честно, не знал что периодичность «регистратор» не использует итоги. Но звучит правдоподобно. Я заинтригован. А вот Вашего пессимизма про индексирование не разделяю.
(6)
А когда в индексировании временной таблицы появляется смысл? Всегда хотел узнать…
ЗЫ: Индекс ведь зачем нужен? Чтобы быстрее найти данные в индексированной таблице. Если взять некую таблицу, то индекс по ней строится за (N * Log2(N))/2 итераций — просто формируем дерево btree, добавляя узел за количество итераций, не превышающих глубину дерева. дерево при этом медленно и верно растет, что в итоге выливается в то самое «/2» в среднем. Дальше по индексу мы найдем за Log2(N) в худшем случае, прочитав дерево на всю глубину. Т.е. в среднем тоже поделим на 2. В обычном неупорядоченном списке сканом мы будем искать за N/2 в среднем. Осталось найти разницу, преодолев которую индексировать становится дешевле. Есть мнение, что это 4 элемента. Уже при 4-х элементах время на индекс = 4 * 2 / 2 = 4, на поиск в среднем по 1 разу на элемент — еще 4. Т.е. 8 вычислений. Для обычного поиска мы найдем все значения за (1+2+3+4) = 10 раз. Т.е. 8 уже меньше 10 (но тут, фактически, паритет, т.к. мы еще потратим 4 на вставку во временную таблицу). Дальше обычный поиск растет линейно к размеру таблицы, а поиск по индексу — логарифмически. Это как бы намекает на то, что: во-первых, не все так радужно, как кажется, а, во-вторых, соединяться нужно по индексированным полям. Но если в соединяете что-то, выбрав все из временной таблицы, по полю, по которому во второй таблице нет индекса, то индексация временной таблицы Вам не поможет.
(15) Пройдите очный курс 1С:Эксперт в Москве, они вам помогут разобраться в теме детально и давать обоснованные советы. Да и 250-500 пользователей одновременно онлайн это не хайлоад, платформа 1С отлично справляется.
(24)
Для достаточно больших таблиц, если обе таблицы содержат X, Y записей и не индексированы то соединение стоит X*Y. Если одна из них индексирована, то соединение стоит X*logY. Если обе индексированы — соединение стоит X+Y. Поэтому на мой взгляд, индексирование имеет смысл.
Скажите, Сергей, в чем я не прав ?
(26)
почему?
(26) В теории все так, но на практике затраты на построение индекса могут превышать полученное уменьшение стоимости соединения. Ну и не стоит забывать про оптимизатор, именно поэтому в спорных случаях надо смотреть план запроса, прежде чем принимать решение об индексировании.
(8)
скажите, пожалуйста, а где об этом можно почитать? Беглое гугление результатов не дало.
(26) похоже на то. Два упорядоченных списка (читай «индекса») можно соединить за Х + У. Фактически мы просто проверяем, равен ли первый элемент первого списка первому элементу второго. Если равен — двигаем «курсор» обоих списков дальше, если нет — двигаем курсор списка, элемент которого меньше. Это применяется, в частности, для Reduce-шага в механизмах MapReduce.
(28)
План одного и того же запроса при высокой селективности отбора и при низкой его селективности может быть разным. Т.е. план зависит от данных — не стоит это забывать. И для компенсации такого поведения обычно в запрос добавляют какое-то поле, например (чтобы для отборов с разной селективностью из процедурного кеша извлекались разные планы запросов, а не один и тот же).
(25) А что не так с советами?
И да, курс пройден.
250 пользователей на слабой машине, после изменения запросов, архитектуры и прочего от виртуалки без потери функциональности отщипнули ресурсов для других целей, количество пользователей постоянно растет, а выбить новые ресурсы очень сложно, и пока справляемся.
Я знаю что 250 это не хайлоад, но там уже база ведет себя не так, как при 50-100 пользователях.
очередной срач к очередному «ПОЛЕЗНО»посту: я думал что нада делать так, а вот замерял и сделал по другому получилось вот так, а вот статья на итс там написано то то … хм иногда делайте так иногда сяк . .. херак херак. Очень полезная статья! Удачи всем в своих замерах и экспериментах (хотел сказать автор в итоге)
(32) В вашем случае, советы, возможно, имеют место на жизнь. Но не стоит забывать, что есть различные поставщики баз данных, наличие DBA так же кардинально может изменить ситуацию (как пример — сжатие БД, распараллеливание записи в tempdb в соответствии с количеством ядерпроцессоров и т. п. ).
У меня бывает до 500 одновременных сеансов и использование индексов намного дешевле чем их не использование, есть действительно запросы которые без индексов выполняются по 30-40 минут, с индексами 2-3 секунды. Ваши советы, не думаю, что будут полезны с большими таблицами (от 100 млн. записей) и размером БД более 1ТБ.
Могу предположить, по вашим словам, что вы упираетесь в дисковую подсистему иили ОЗУ. И улучшение железа — дешевле чем оптимизация.
Меня одного смутила выборка из оборотного регистра продаж под псевдонимом остатка товаров?
(32) Интересно, было бы, увидеть аналитику по ключевым операциям и расчет денежных потерь, «отказов» обслуживания клиентов по этим ключевым операциям.
(33) Нет, Вы не так поняли. Я сделал «как в учебнике» и получилось хорошо. Никаких разночтений и шатаний.
(35) Исправил псевдоним. Спасибо за внимательность.
(7) Хорошо когда доступ к телу есть, к SQL то ))
Отбор по номенклатуре выдает 99% справочника — зачем удивляться, что условие ГДЕ по скорости примерно равно условию в виртуальной таблице?
А то, что номенклатура в списке ищется медленнее, чем в индексированной временной таблице, вполне может зависеть от версии СУБД. Не понятно, кстати, почему автор не пишет больше о условиях тестирования.
Если в приведенном запросе убрать индексирование, но оставить как есть (через виртуальную таблицу) — сколько времени занимает выполнение?
Показать
(41) У меня изменение времени выполнения составило менее 5%, номенклатуры в первой таблице около 20 000, строк результа около 500 000.
(41) (42) Коллеги, постараюсь Вам ответить сегодня-завтра.
(41) (42) (40) Насколько я понял,
1. Если условие является неэффективным, то почти нет разницы, где оно стоит.
2. Для индексированного условия достигается существенный выигрыш.
(44) В теории достигается, а на практике (например, на моей базе 🙂 ) все может быть не совсем так. Но в приведенном в (41) запросе не индексировать временную таблицу смысла нет, там не будет миллионов записей, и затраты на индексирование будут относительно невелики
(45) если ВТ сама по себе небольшая, то оптимизатор SQL сервера скорее всего примет решение не использовать индекс, а выполнить сканирование таблицы, так как это более выгодно. — и в результате получим ситуацию — ресурсы на построение индекса затратили, но он использоваться не будет.
Если возникают ситуации, что требуется соединения с большими выборками данных — то скорее всего что то не так с самой задачей
(46) Небольшая это сколько? Если 1000, то затраты на построение индекса минимальны, если для оптимизатора небольшая это 100 000 тогда еще стоит об этом всерьез задуматься.
Соединения с большими выборками данных обычно возникают, когда на имеющейся структуре данных требуется строить какие-либо нестандартные выборки, не предусмотренные архитектурой приложения. А менять архитектуру не всегда возможно…
(36) На текущем месте работы данная информация совершенно никому не интересна, времени на то, что бы настроить сбор, мониторинг не выделяется, я уже как то имел глупость предложить внедрить хотя бы тот же апдекс, понимания ни в глазах коллег ни в глазах руководства не увидел. Да что там говорить отдел ИТ 1.5 года категорически не хочет давать доступ к профайлеру, только за их терминалом на их рабочем месте, кручусь, как могу.
По факту результат такой: у пользователей всё тормозит — покопался — больше не тормозит.
(47) Что оптимизатор посчитает большим или нет в момент первого выполнения предсказать невозможно, можно попытаться спрогнозировать, очень сильно зависит от актуальности статистики, и даже от того будут ли при первом выполнении поля поиска высоко селективны или нет, на подготовке эксперту такой пример, кстати, демонстрируют.
(41) конкретно в данном примере скорее всего эффект будет гомеопатический, причем предсказать в какую сторону, я не могу, для оптимизатора этот запрос — легкий. Так же надо понимать, что план запроса в данном примере с индексировать и без может отличатся, потому что текст запроса будет отличатся, в кеше планов нет плана на этот текст запроса и исходя из своей логики он может подобрать абсолютно другой план, а может такой же. Но по своей практике с более сложными запросами: с индексировать — около секунды , к примеру, без него — быстрее — как правило, в разы быстрее — иногда. Есть всего только один пример, когда без индексировать 2 секунды, с ним — 0,05 с, и что самое интересное в нем нет соединений, а запрос вида выбрать строчки из таблицы, потом их сгруппировать, так вот, если сделать в 2 пакета и проиндексировать по полям группировки, а не в одном запросе, результат в 40 раз быстрее, причина не ясна, статистика актуальна, текст запроса искусственно менял, для того что бы сгенерировался новый план, поля отбора высоко селективны, и хоть бы фиг. Но это всего один запрос из вообще всех….
Коллеги, продолжение