каким mysql запросом связать строки из двух таблиц у которых между собой нет жесткой связи по полю id?

select … from db1.table1 t1, db2.table2 t2 where t1.f1=t2.f1 and t1.f2=t2.f2

Или тебе надо выборку по небольшому интервалу? Разницу можно прикрутить, но будет медленно же.

и по третьему полю 'время' нужно связать. Эти поля не ,бьются точь в точь , в интервале как то нужно с переводом полей в формат UNIXTIME,

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

и еще добавлю, ИНТЕРВАЛ ВРЕМЕНИ в котором ищутся записи в разных таблицах ИЗВЕСТЕН, как и значения двух полей.

Ну сделай разницу, в чем беда-то.

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

Как запросом можно упорядочить по возрастанию строки одной таблицы по полю datetime, затем упорядочить так же строки второй таблицы, а после слить в одну таблицу ? ( с учетом того что число строк в таблицах одинаковое за период, если разное то непонятки)

Разница по AVG?

Если у тебя контролируемый интервал и в него попадает больше 2х записей, сделай разницу от AVG. С оконными функциями все плохо(

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

не понял

с JOIN стало 8 строк )), больше чем если объединять через WHERE
какой JOIN правильнее использовать?

AVG(t1.f3) - AVG(t2.f3) < xz group by …

join тут вообще не нужен, у тебя прямая выборка.

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

xz это что?

интервал твой, я же его не знаю

Проблема в том что в интервал, который требуют, попадает несколько строк

Погоди а ты среди них как нужную должен найти?

Могут быть и по две и по три строки в левой и правой таблице которые попадают в интервал, может даже в левой быть 2 строки а в правой 3. Сматчить их на 100% не получается пототому что время в левой и правой табличке не совпадает.

AVG - это же среднее по нескольким значениям, к нему нужно GROUP BY? Разбежка по времени между строками левой и правой таблицы 1-5 секунд, а интервал времени для поиска строк может быть в 10-20 раз больше разбежки.

Ну тогда логично, что число записей больше суммы числа строк в обеих таблицах. А ты вообще какой результат получить хочешь?

с JOIN стало

в смысле «с»? не использовать JOIN для соединения таблиц в 2023 году это как писать новый ынтерпрайз прожэкт на COBOL. Нет, лучше на RPG.

не хочешь писать group by пиши avg( … ) over ( partition by … )

Подсказывали выше, оставить в выводе запроса c JOIN строки таблиц у которых минимальное расхождение между таймстампами. Хотя по какому условию отфильтровать эти строки, тоже вопрос.

минимальное расхождение между таймстампами

Ну это уже условие, но это точно те строки? Если да, то можно через подзапрос или ЦТЕ (хз что у тебя за база) населектить строки где дифф минимален.

select * from t1 join t2 on усл1 and усл2 and abs(t1.dt - t2.dt) < сколько-то_секунд

не?

между собой нет жесткой связи по полю id?

На мягкой связи можешь сделать только связь говна. Придумай по каким данным можно связать записи однозначно. Без этого, на костылях разного сорта, получится только данный результат.

в таблицы данные попадают с разных серверов у которых может отличаться время - до 5-10сек (не принципально на самом деле).

Может время синхронизировать на серверах для начала?

кто сказал, что проблема в этом лол

ясен пень что если в этом, то чинить надо её но и в этом случае не факт что это возможно.

Обст-ва за пределами ОП ясно дело на совести адекватности ТСа.

а если это невозможно? скажем, сбор данных настроен на двух серверах определённым образом и изменить это (тем более фундаментально) абсолютно не в силах ТСа?

кто сказал, что проблема в этом лол

Как кто? ТС и сказал. Проблема с пониманием прочитанного?

Возможно и так, я (бегло) прочитал это по-другому - ТС очень экономно расходует знаки препинания.

Остальное не меняется - починка этого легко может быть за пределами возможностей ТСа.

У самого на работке сервак с левым временем. Я к этому отношения не имею никакого.

Ну тогда задачу надо решать фундоментально, пригласить DBA и бормоча «консистентность», «формальность», «строгость» запилить правильную бд, лить данные в нее и селектить оттуда.

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

Тут всё просто - чинить это, либо делать, как я выше написал. Какие ещё вар-ты не знаю.

я согласен, что говно. если в левой таблице три строки, а в правой две. вот и случилось говно.
введение уникального id для двух таблиц потребует переделать систему, переместить начальную точку генерации событий, чтобы появился этот уникальный id.
А это меняет очень много и сколько времени займет разработка и отладка ХЗ.

в левой таблице три строки, а в правой две

а можно для любопытных пояснить - что вы на выходе ожидаете? LEFT, RIGHT, CROSS, FULL ?

Какой результат-то считаете правильным? три? две? пять?

И поле с меткой времени какое ожидается на выходе? минимальное в допустимом интервале? максимальное? среднее?

+ зависит от разработчика покупного ПО которое генерит события, захочет ли разработчик в генерируемые события вставить поле с временем. и если захочет, то сколько это будет стоить

«а можно для любопытных пояснить - что вы на выходе ожидаете? LEFT, RIGHT, CROSS, FULL ?» - это для меня не понятно.

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

да, такой запрос и получился.

а если это невозможно?

Ну если ты в своей ИС никто, то с этим однозначно надо что-то делать.

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

У тебя там микросервисы штоли?

+ зависит от разработчика покупного ПО

Купили херню, чтобы она решила проблемы, она проблемы решила, но есть нюанс.

если ты в своей ИС и прогер и админ и на дуде игрец, то ты работаешь в калхозе.
с этим можно ничего не делать.

И его работоспособность целиком зависит от разницы во времени, которая не обязана быть в каких-то рамках.

введение уникального id для двух таблиц потребует переделать систему

Да так-то связать два события - задача тривиальная, надо только прорваться через сраку уже написанного.

А что ты так реагируешь? Если ты там «не в силах», тут «не в силах», то ты импотент и у тех, кто что-то хочет могут возникнуть вопросы.

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

а если джойнить

ТС так и не рассказал свою задачу.

Возможно тут вообще не JOIN, а UNION.

типа: «есть два лога событий из разных источников в разных БД, хочу получить из них один лог, в котором при совпадении полей 1 и 2 считать события в рамках 5 секунд как одно»

тогда что-то вроде timediff(c3, LEAD(c3)) над UNION обеих таблиц, наверное.