# The best query batching methods

**URL:** <https://forums.percona.com/t/the-best-query-batching-methods/26077>\
**Category:** Other MySQL® Questions\
**Created:** [October 21, 2023, 12:37am UTC](https://forums.percona.com/t/the-best-query-batching-methods/26077 "2023-10-21T00:37:29Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dkang](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/dkang/32/9269_2.png) [@dkang](https://forums.percona.com/u/dkang)\
**Post date:** [October 21, 2023, 12:37am UTC](https://forums.percona.com/t/the-best-query-batching-methods/26077/1 "2023-10-21T00:37:29Z")

</div>

These are different request batching methods:

1. make 2 concurrent requests with 2 tcp connections:  
session1 - “SELECT \* FROM table WHERE key = 1;”  
session2 - “SELECT \* FROM table WHERE key = 2;”

2. concatenate SQL statements with semicolons;  
“SELECT \* FROM table WHERE key = 1; SELECT \* FROM table WHERE key = 2;”

3. merge them with IN  
“SELECT \* FROM table WHERE key IN (1, 2);”

Are 1, 2 slower than 3 because they open/lock the table twice? Or immediately accessing the same table one after another is just as fast as 3?

What’s the best practice for performance? WHERE … IN cannot be used with inequalities so 3 cannot be generalized.

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [October 21, 2023, 2:39pm UTC](https://forums.percona.com/t/the-best-query-batching-methods/26077/2 "2023-10-21T14:39:48Z")

</div>

You forgot #4 🙂

```
SELECT * FROM table WHERE key = 1
UNION
SELECT * FROM table WHERE key = 2

```

In this very specific example, #3 would be faster (by 0.001%, I’m joking here, I’m generalizing) because values 1 and 2 are extremely likely on the same page. #1 requires 2 different TCP connections, 2 different threads, 2 different txn views, 2 passes through the query optimizer/parser, etc. There’s no table locking on SELECTs in InnoDB.

IN() clauses become worse when you have 100s or 1000s of entries. In this case, better to create a temporary table populated with the IN() values and JOIN to the table.