Inconsistent Query Behavior with IN Clause for SELECT and UPDATE/DELETE Statements on Vindexes about vitess

[mattlord]

/cc @vitessio/query-serving on this and the PR: #15455

[mattlord]

Just noting that the results are the same on main today:

mysql> vexplain queries select * from test_vindex_signed_int where v_key in  (1,100);
+------+----------+-------+-------------------------------------------------------------------+
| #    | keyspace | shard | query                                                             |
+------+----------+-------+-------------------------------------------------------------------+
|    0 | customer | -80   | select id, v_key from test_vindex_signed_int where v_key in (1)   |
|    1 | customer | 80-   | select id, v_key from test_vindex_signed_int where v_key in (100) |
+------+----------+-------+-------------------------------------------------------------------+
2 rows in set (0.01 sec)

mysql> vexplain /*vt+ EXECUTE_DML_QUERIES */ queries update test_vindex_signed_int set id = id + 100 where v_key in (1,100);
+------+----------+-------+-------------------------------------------------------------------------+
| #    | keyspace | shard | query                                                                   |
+------+----------+-------+-------------------------------------------------------------------------+
|    0 | customer | 80-   | begin                                                                   |
|    0 | customer | 80-   | update test_vindex_signed_int set id = id + 100 where v_key in (1, 100) |
|    1 | customer | -80   | begin                                                                   |
|    1 | customer | -80   | update test_vindex_signed_int set id = id + 100 where v_key in (1, 100) |
+------+----------+-------+-------------------------------------------------------------------------+
4 rows in set (0.00 sec)


❯ vtgate --version
vtgate version Version: 20.0.0-SNAPSHOT (Git revision 3ae5cf7e690e560dd5630119215bcc3f5ecf31c8 branch 'main') built on Tue Mar 12 12:20:18 EDT 2024 by [email protected] using go1.22.1 darwin/arm64

[harshit-gangal]

This is not a correctness issue as it does not make the database inconsistent in any way.

[harshit-gangal]

I have removed the Bug label from it, there can be some performance improvement if the list is very big like 1000 or 10000 and we send only a limited list to each shard.

[wangweicugw]

This is not a correctness issue as it does not make the database inconsistent in any way.

Understood, thank you for your explanation. My description was not accurate; this is indeed not a bug.we can still discuss how to optimize performance to be more efficient when dealing with large volumes of data.