MySQL и парадокс c LEFT JOIN ON(...) — где логика?

Question

[AShvejnov]

Столкнулся в работе с интересным явлением. База MySQL 5.7.26 (всё в UTF-8 и только).

Есть две таблицы, предположим. В обеих таблицах есть поля с уникальными значениями, являющимися по факту артикулами товаров. При этом в первой таблице это поле числовое, т.к. в ней хранятся только товары с целочисленными артикулами. А во второй таблице уже это поле VARCHAR(30), так как там лежит информация по артикулам, но в том числе там уже встречаются и артикулы смешанного вида, поэтому VARCHAR.

Структура table1:



Содержимое table1:



Структура table2:



Содержимое table2:



И вот в чём парадокс. Возникает он, когда делаем простейший запрос с LEFT JOIN, соединяя таблицы по сквозному полю с ID товара.

Если сделать вот такой запрос:

SELECT t1.t1_id, t2.* 
FROM table1 t1 
LEFT JOIN table2 t2
ON(t1.t1_id = t2.t2_id)

То получаем вот такой неожиданный/нежелательный результат:



...а если в условии ON(...) тупо меняем оператор = на LIKE:

SELECT t1.t1_id, t2.* 
FROM table1 t1 
LEFT JOIN table2 t2
ON(t1.t1_id LIKE t2.t2_id)

...то получаем другой результат, желаемый (только точные соответствия 1-к-1):



Вопрос: почему так? О__о

Я бы ещё мог ожидать обратного результата, если бы по LIKE цеплялись бы не только 1:1 соответствия, но ещё и какие-то похожие с суффиксами. Но тут же получается наоборот - вроде как требуем точного соответствия (=), а получаем в том числе и неточные. А по LIKE при этом наоборот получаем только 1:1 точные...

P.S. Если в обеих таблицах поле с ID сделать VARCHAR, то проблема уходит сама собой. Но это не отменяет вопроса, почему такой парадокс происходит, когда в одной таблице INT, а в другой VARCHAR.

Answer 1

[Melkij]

Никакого парадокса, задокументированное поведение. Скопирую недавний ответ отсюда:

Потому что вообще не надо сравнивать строки и числа. Если поле строковое - сравнивайте только со строкой. Хоть при этом происходит и вполне задокументированное поведение.

Comments

[AShvejnov]

Спасибо! А в конфиге нигде нет какой-нибудь "ручки", которую можно дёрнуть, чтобы активировать автоматическое приведение типов при сравнении? (узнаёте сразу адепта PHP, да? хаха)

[AShvejnov]

Я правильно понимаю, что замена = на LIKE как временное решение данной проблемы - это вполне себе решение при условии отсутствия большой нагрузки / больших объёмов данных? Или это от лукавого и так лучше не делать?

[Melkij]

чтобы активировать автоматическое приведение типов при сравнении?

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

При том как раз симметрично

php > var_dump(123 == '123_suffix');
bool(true)

[AShvejnov]

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

<?php

$foo = 123;
$bar = '123_suffix';

var_dump($foo == $bar);

if( $foo == $bar )
	echo 'true, but ' . var_dump($foo == $bar);
else
	echo 'false, but ' . var_dump($foo == $bar);


var_dump(123 == '123_suffix');


?>

bool(true)
true, but bool(true)
bool(true)

Даа... есть что переосмыслить. Спасибо ещё раз!

[AShvejnov]

Просто интересно (и про MySQL, и про PHP) - если такое поведение задумано и задокументировано, то в каких случаях оно может оказаться наоборот полезным/ожидаемым/применяемым? Я про 123 == "123_something". И каково соотношение количества случаев, когда оно полезно, с количеством случаев, когда оно вредительно/неожидаемо. Так, чисто с точки зрения рядового потребителя/пользователя интересно вот...