Bug #119168 Inconsistent results for CHAR IN (subquery returning BIT)
Submitted: 16 Oct 2025 8:47 Modified: 14 Jan 14:51
Reporter: zz z Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S3 (Non-critical)
Version:9.4.0 OS:Any
Assigned to: CPU Architecture:Any

[16 Oct 2025 8:47] zz z
Description:
A query that uses an IN clause to compare a CHARACTER type column against a subquery returning a BIT type column yields inconsistent results between the optimized execution plan and the unoptimized row count calculation. The optimizer correctly evaluates the implicit type conversion, resulting in a TRUE condition, while the unoptimized path incorrectly evaluates it as FALSE.

How to repeat:
CREATE TABLE t1529 (c1 CHARACTER, c2 BIT NOT NULL);
INSERT HIGH_PRIORITY IGNORE INTO t1529 (c1,c2) VALUES ('r',b'1');
INSERT INTO t1529 (c1,c2) VALUES ('v',b'1');
INSERT HIGH_PRIORITY IGNORE INTO t1529 (c1,c2) VALUES ('c',b'1');
INSERT IGNORE INTO t1529 (c1,c2) VALUES ('a',b'0');

SELECT ca6 FROM (SELECT c1 ca4, c1, c2 ca6 FROM t1529) ta1 WHERE (((((c1)) IN (SELECT c2 FROM t1529))));
-- Returned Row Count: 4

SELECT SUM(count) FROM (SELECT ((((((c1)) IN (SELECT c2 FROM t1529))))) IS TRUE AS count FROM (SELECT c1 ca4, c1, c2 ca6 FROM t1529) ta1) AS ta_norec;
-- Returned Row Count: 0
[14 Jan 14:51] Øystein Grøvlen
Verified as described on 9.5.0.
I do not see the issue on 8.4.6 or 8.4.7.