[MDEV-11224] Select with multiple conditions (one of them IS NULL) using a composite index against a federated table returns empty result set Created: 2016-11-02  Updated: 2020-12-01

Status: Confirmed
Project: MariaDB Server
Component/s: Storage Engine - Federated
Affects Version/s: 10.2.1, 5.5, 10.0, 10.1, 10.2.2, 10.2
Fix Version/s: 10.2

Type: Bug Priority: Major
Reporter: Wolfgang Walther Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: upstream


 Description   

Appends earlier versions as well.

Put together:

  • a federated table
  • a composite index
  • a select with condition column IS NULL and at least one other condition, both in the composite index
    and the result will be an empty result set, even if there should have been rows returned.

Bug does not occur, when:

  • single column index is used or
  • no index is used or
  • condition IS NULL is only condition or
  • condition IS NOT NULL is used instead

Test case:

-- use this server as remote and local server for test-case
-- bug behaviour is the same with 'real' remote server
DROP SERVER IF EXISTS local_server;
CREATE SERVER local_server
FOREIGN DATA WRAPPER mysql
OPTIONS (
  HOST '127.0.0.1',
  PORT 3306,
  USER 'USER',
  PASSWORD 'PASS',
  DATABASE 'test'
);
 
-- create sample table and fill with data
DROP TABLE IF EXISTS test.remote_table;
CREATE TABLE test.remote_table (
  a TINYINT DEFAULT NULL,
  b TINYINT NOT NULL,
  KEY _ab (a,b),
  KEY _ba (b,a),
  KEY _a (a),
  KEY _b (b)
) AS
SELECT NULL AS a, 1 AS b
UNION
SELECT 2 AS a, 3 AS b;
 
-- create federated table pointing to table above
DROP TABLE IF EXISTS test.local_table;
CREATE TABLE test.local_table (
  a TINYINT DEFAULT NULL,
  b TINYINT NOT NULL,
  KEY _ab (a,b),
  KEY _ba (b,a),
  KEY _a (a),
  KEY _b (b)
) ENGINE=federated CONNECTION='local_server/remote_table';
 
-- remote table: OK
SELECT * FROM test.remote_table
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- not using index: OK
SELECT * FROM test.local_table USE INDEX ()
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- use column index a: OK
SELECT * FROM test.local_table USE INDEX (_a)
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- use column index b: OK
SELECT * FROM test.local_table USE INDEX (_b)
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- use composite index, a is NOT null: OK
SELECT * FROM test.local_table USE INDEX (_ab)
WHERE a IS NOT NULL AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- use composite index, a=2: OK
SELECT * FROM test.local_table USE INDEX (_ab)
WHERE a=2 AND b BETWEEN 1 AND 3;
-- returns 1 row
 
-- use composite index, only one condition: OK
SELECT * FROM test.local_table USE INDEX (_ab)
WHERE a IS NULL;
-- returns 1 row
 
-- use composite index, a first column, a is null: WRONG
SELECT * FROM test.local_table USE INDEX (_ab)
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns no rows
-- should return 1 row
 
-- use composite index, a last column, a is null: WRONG
SELECT * FROM test.local_table USE INDEX (_ba)
WHERE a IS NULL AND b BETWEEN 1 AND 3;
-- returns no rows
-- should return 1 row



 Comments   
Comment by Elena Stepanova [ 2016-11-03 ]

Thanks for the report.
Reproducible on all of 5.5, 10.0, 10.1, 10.2, both with Federated and FederatedX.
Also reproducible with MySQL 5.7.

FederatedX allows to see queries from local to remote in the general log. It shows that it transforms the problematic query into something really weird:

5 Query     SELECT * FROM test.local_table USE INDEX (_ab) WHERE a IS NULL AND b BETWEEN 1 AND 3
3 Query     SHOW TABLE STATUS LIKE 'remote_table'
3 Query     SELECT `a`, `b` FROM `remote_table` WHERE  (`a` IS NOT NULL  AND  (`b` >= 1) ) AND (`a` IS NOT NULL  AND  (`b` <= 3) )

The clause USE INDEX itself is not a culprit, but it's good to make sure it's reproducible reliably. In my setup at least the query uses this index without any hints.

wollewalda, did you happen to report it to upstream as well?

Comment by Wolfgang Walther [ 2016-11-05 ]

@ElenaStepanova: No, I didn't report it upstream, as I didn't want to go through the hassle of registering with Oracle...

Comment by Elena Stepanova [ 2016-11-16 ]

Re-filed as http://bugs.mysql.com/bug.php?id=83851

Generated at Thu Feb 08 07:48:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.