Feb 16 07:07
Используются 2 индекса - и оба индекса для данного запроса ни о чём.. удалите оба (или по крайней мере первый) и создайте композитный индекс. через microtime на этот фрагмент уходит около 5 секунд. Профилируйте запрос и накладные расходы на него. Полагаю. основное время уходит не на выполнение запроса, а на передачу данных.
 
Oct 21, 2024 20:44
Пожалуйста, переместите все факты в текст вопроса. В комментариях всё это просто нечитаемо. И уберите упоминание о MySQL - нерелевантно.
 
Apr 25, 2024 11:12
Ещё раз повторю вопрос - транзакция организована в программе на шарпе, средствами шарпа, или в исполняемом SQL-сервером наборе запросов, средствами SQL?
Apr 25, 2024 11:12
А каким боком тут коммиты других транзакций? какое они имеют отношение к проблеме, зачем вообще о них упоминать? И так-то ничего не ясно.. что происходит, где происходит, что собственно мешает контролировать состояние по мере выполнения транзакции (кстати, организованной где и какими средствами?) и записывать нужную для рассмотрения, анализа и отладки информации в нетранзакционную отладочную таблицу...
Apr 25, 2024 11:12
у меня в коде формируется огромная транзакция из десятков таблиц. Естественно в какой-то из них происходит ошибка и транзакция завершается с ошибкой. При этом в логах ничего не пишется кроме факта коммита. Никаких ошибок. Вообще ничего не понять... в чём происходит ошибка - в таблице? Что за бред? Как транзакция, завершённая с ошибкой, может завершиться коммитом??? Вообще дважды бред.
Apr 25, 2024 11:12
у меня в коде формируется огромная транзакция из десятков таблиц Транзакция - в коде на шарпе, что ли? тогда поневоле вопрос - а какие претензии к MySQL? То, что ошибка с точки зрения шарпа, вовсе необязательно ошибка и с точки зрения СУБД. И да, транзакция состоит не из таблиц, а из выполняемых операторов (statement), таблицы в транзакции могут использоваться и/или модифицироваться.
Apr 25, 2024 11:12
все мануалы только про обычные логи Гм... а бывают необычные? Вообще-то есть только один Reference Manual, всё остальное - это сочинения по мотивам. Вот глава о логах: MySQL Server Logs. General Log + Error Log + знание того, что и в каком порядке выполняется из приложения - вполне достаточно для анализа ситуации.
 
Feb 8, 2024 14:13
@teran план выполнения запроса меняет порядок таблиц, и сортируется не по полю основной таблицы Запрос - INNER JOIN, так что ни основных, ни не-основных таблиц тут просто нет. В каком порядке серверу захочется, в таком и будет сканировать. Пока не появится STRAIGNT_JOIN.
Feb 8, 2024 14:13
Для показанного запроса мои индексы - покрывающие. Приведённый мной fiddle с планом показывает, что они используются - то есть сервер не обращается к самим таблицам вообще. А вот от финальной сортировки ну никуда не убежать.
Feb 8, 2024 14:13
Чисто по тексту запроса хочется предложить индексы: news (type, id, public_date) и news_rayon (rayon_id, news_id). Посмотри, как их создание повлияет на план и время выполнения. Если они не используются, посмотри на время с хинтами на эти индексы. dbfiddle.uk/VAuPX0ae
Feb 8, 2024 14:13
А статистику данных и планы запросов? что анализировать-то? На пустых таблицах я вижу dbfiddle.uk/okdQv6T2
Feb 8, 2024 14:13
Полные CREATE TABLE, статистику по данным - общую и в разрезе отдельных условий, планы всех запросов - в студию.
 
Dec 13, 2023 20:11
@AlexeyTrukhanov Да, MERGE использует JOIN, который не требует наличия индекса.
Dec 13, 2023 20:11
Нет-нет. Уникальное ограничение обязано быть... Сервер проверяет условие конфликта по индексу либо констрейнту - шерстить всю таблицу он не будет.
Dec 13, 2023 20:11
@AlexeyTrukhanov Обновление в ON CONFLICT выполняется в случае, если срабатывает ограничение уникальности (если в таблице их несколько - любое из них), а также при выполнении дополнительного условия-ограничения (если таковое имеется в запросе). Иначе выполняется вставка.
Dec 13, 2023 20:11
@AlexeyTrukhanov Почти. Всегда используйте полное именование, включающее имя таблицы. Для исключения неоднозначностей. update set dest.value1 = source.column1, dest.value2=source.column2. Серверу пофиг, а порядка будет больше.
Dec 13, 2023 20:11
@AlexeyTrukhanov то есть задача - просто преобразовать набор значений (полученный клиентом массив) в rowset в тексте запроса. Для этого используется показанным выше образом ROW constructor, а для именования полученного набора записей указываются алиасы набора и полей.
Dec 13, 2023 20:11
@AlexeyTrukhanov как это должно быть синтаксически - не понимаю .. USING ( VALUES (1,2), (3,4), (5,6) ) AS source (column1, column2) ..
Dec 13, 2023 20:11
@AlexeyTrukhanov MERGE более гибкий. Но на твоей задачи эта гибкость не нужна. Так что имхо именно в твоём случае INSERT .. ON CONFLICT достаточен.
 
Dec 4, 2023 21:49
The issue I'm running into is that I think I have to make sure the two routers have different IP addresses The routers must have IP addresses which belongs to different subnets.
 
Oct 24, 2023 11:34
Ну например читать строки, считать хэши, и сохранять только хэш и смещение строки в файле. При проверке искать хэш, если найден - читать и сверять оригинальную строку.
 
Sep 6, 2023 12:07
SELECT EXISTS (SELECT NULL FROM sessions WHERE session_hash = $hash) row_exists; - вернёт 1, если такой хэш есть в таблице, и 0 - если его нет. Максимально быстро (быстрее LIMIT 1, тем более быстрее SELECT COUNT()) - поиск заканчивается при обнаружении любой соответствующей записи. Для ускорения поле session_hash должно быть индексировано.
 
Feb 11, 2023 01:47
This is NOT MySQL who cuts your data off. Investigate your client software or programming language settings.
 
Jul 17, 2022 08:05
Вы уже задавали этот вопрос.Через штатный CLI (mysql.exe) запросом LOAD DATA.
Jul 16, 2022 05:35
Тем не менее это быстрее. Как правило - заметно быстрее.
Jul 15, 2022 12:06
А что Вы предлагаете модифицировать-то? как по мне, так надо 1) уменьшить длины полей - вряд ли 100 символов реально требуется; 2) Попробовать, сколько времени займёт импорт, если удалить индекс по login, загрузить данные (должно потребоваться порядка 8-10 минут) и потом заново создать индекс.
Jul 15, 2022 10:31
Я имею в виду dev.mysql.com/doc/refman/8.0/en/… и чуть подробнее dev.mysql.com/doc/refman/8.0/en/sorted-index-builds.html - но это глобальная установка, которые вообще лучше без очень весомых причин не тормошить...
Jul 15, 2022 07:34
Ускорить процесс можно изменением настроек и увеличением объёма свободного пространства в странице индекса при расщеплении. Дефолтно там, емнип, 1/16, можно попробовать увеличить процентов до 40. Индекс, конечно, распухнет, но количество расщеплений понизится, и в общем вставка должна ускориться.
Jul 15, 2022 07:32
Ага, при добавлении идёт одновременное перестроение-пополнение индекса по login. А с учётом того, что значение login - это полтаблицы, неудивительно, что удвоение объёма сопровождается удвоением времени.
Jul 15, 2022 04:30
@AndreyLaki Индекс как раз и стоит в login Я просил же показать полный CREATE TABLE. Неужели так трудно выполнить SHOW CREATE TABLE tablename; и скопировать результат сюда? а из скриншота DESC ни хрена не видать... secure files я изменял в my.ini(вроде), и после перезапуска сервера он восстанавливается, хоть и сохраняю Значит, правил либо не тот файл, либо не последний из загружаемых. Добавь лучше установку в командную строку запуска сервиса.
Jul 14, 2022 15:45
У меня проблема с secure files. Когда очищаю его путь, он восстанавливается Так надо его изменять или в конфигах, или в командной строке сервера.
Jul 14, 2022 15:44
@AndreyLaki Структура ibb.co/NFdXRzc. Поскольку в структуре нет индексов, а первичный ключ синтетический, то замедление - это более чем странно. Я не думаю что копирование как то влияет Ну да... а то, что файл-источник копируется и расходует и время, и дисковое пространство - это типа ерунда? кстати, а что со свободным местом на диске?
Jul 14, 2022 13:24
@AndreyLaki Не понял... откуда столько предупреждений? и что за предупреждения? И покажите структуру таблицы (полный CREATE TABLE) и пример импортируемого файла (3-5 строк). Да, сколько времени занимает копирование файла во временный каталог? что если файл сначала зааплоадить на сервер, а потом импортировать без LOCAL?
Jul 14, 2022 12:59
Я произвожу импорт через OpenServer посредством Консоли Яне использую OpenServer и понятия не имею, что там есть Консоль. Через что вы импортируете? Через штатный CLI (mysql.exe) запросом LOAD DATA.
Jul 14, 2022 12:57
Если же импортировать другой файл, того же размера, то импорт займёт приблизительно то же время. Разница будет зависеть от процента дубликатов, и может быть как в минус (до приблизительно 60-70%), так и в плюс (до приблизительно 50%).
Jul 14, 2022 12:57
Попробуйте еще раз сделать импорт такого же файла, в ту же базу данных, она примерно будет импортироваться 22 минуты Нет. Наоборот, повторный импорт того же файла (при котором все записи будут отвергнуты как дубликаты) будет выполнен намного быстрее (по опыту и с учётом производительности моей системы процесс займёт порядка 4 минут).
Jul 14, 2022 12:07
Вот только что закончил импорт через LOAD DATA файла, 5 Гбайт, 11млн. записей, с препроцессингом, всё заняло 11 минут. Вы явно выполняете какой-то другой "импорт".
Jul 14, 2022 12:07
Повторю. Что такое импорт в данном конкретном случае? Как точно он выполняется? в подробностях.
Jul 14, 2022 12:07
Импортировал файл на 2 гб(2 часа импорта) Чистый LOAD DATA импортирует гораздо быстрее. Что там ещё наворочено поверх процесса импорта?
Jul 14, 2022 12:07
Отключить проверку при импорте MYSQL? Проверку чего именно? При импорте файла у меня производится проверка файла, чтение всех строк, после чего идёт сам импорт. ??? Если используется LOAD DATA, то никаких отдельных проверок, чтений, импортов - нет. Выполняется единый процесс потокового копирования.
 
Feb 1, 2022 14:27
@ЮрийКозлов Можно обойтись без центра трансформации. Достаточно ориентации прямоугольника и соотношения его сторон. Все вершины рассчитываются из этого, поскольку начальное положение на них не влияет Да блин же ж... есть 4 вершины: (0,0),(0,1),(2,0),(2,1), увеличиваем ровно вдвое, посчитайте вершины увеличенного прямоугольника.
Feb 1, 2022 14:27
@ЮрийКозлов Но имея начальное положение прямоугольника: размеры, ориентацию и координаты какой-то одной вершины, можно рассчитать его положение после трансформации Угу, вот эта вершина и есть центр трансформации. Возьми другую вершину - и получишь после трансформации совсем другие координаты остальных трёх вершин.
Feb 1, 2022 14:27
@ЮрийКозлов ??? Если выполнять такое смещение до масштабирования, хрен чего получится, ибо прямоугольничек маловат, и вот хоть обдвигайся, а больше двух не положишь, третью лишь если случайно начальный размер подходящий. А если после, то в лучшем случае только одна точка прямоугольника останется на своём начальном месте, а где будут все остальные, неизвестно, и соответственно неизвестно, куда и насколько двигать.
Feb 1, 2022 14:27
@ЮрийКозлов Тогда задача вообще сводится к расчёту длины проекции квадрата на прямую, проходящую через короткую сторону прямоугольника. А понятие смещения так и вовсе теряет смысл.
Feb 1, 2022 14:27
Дело в том, что если таковой точки нет, то невозможно посчитать координаты после масштабирования. Так что точка, относительно которой выполняется масштабирование, обязана быть.
Feb 1, 2022 14:27
Угу... осталось понять, относительно чего можно/нужно масштабировать (со смещением всё вроде понятно, после нормализации прямоугольника смещать надо как раз квадрат). Если выбор точки масштабирования произволен, то при не-единичном коэффициенте всегда есть точка, относительно которой требуемое смещение будет нулевое.
 
Jan 7, 2022 17:59
@andreymal Ну собственно уже описаны три разные технологии хранения, под разные требования конечного пользователя. Пусть автор решает, что ему нужно. Или более подробно описывает задачу.
Jan 7, 2022 17:59
@andreymal Стоп. Это вообще третья задача получается. Это - задача хранить время, которое может измениться физически - то есть астрономический момент времени на момент записи в БД и астрономический момент времени на момент получения сохранённого значения - не совпадают. БД на такое не рассчитана как бы... при именно такой постановке - храните дату и время в локальном представлении в текстовом поле с указанием зоны. В MySQL для именно такой задачи встроенного типа данных - нет.
Jan 7, 2022 17:59
@andreymal Новые настройки целевой зоны времени, той, в которой следует представить хранимое значение. Какие ж ещё?