Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

eggplantSword's avatar

Api endpoint throws sql error, too many ids in where in

SQLSTATE[HY000]: General error: 1 too many SQL variables (SQL: select * from "sale_points" where "sale_points"."uuid" in (98cc2251-4665-46f2-afbf-ed432a69555b, ..., 98cc225f-3f4c-4 998135d4-14de-4376-b91b-ecefff1ebf1c, 99c16b76-1721-4668-8d50-460ae6c115af)) at /home/salcom/public_html/sam-central/vendor/laravel/framework/src/Illuminate/Database/Connection.php:760)

This error popped up in production today but there haven't been any changes in the code so I don't know what is happening.

This is the method there it fails, this is an api backend

    public function salePoints($action, $updatedAt = null)
    {
        if ($action === SyncAction::MASTER->value)
//fails on the line below
            return GpsSalePointResource::collection(SalePoint::withTrashed()->with('salePoint')->oldest()->lazy())->resolve();
        else
            return GpsSalePointResource::collection(SalePoint::withTrashed()->with('salePoint')->whereTimestamps('>', Carbon::parse($updatedAt))->oldest()->lazy())->resolve();
    }

GpsSalePointResource

class GpsSalePointResource extends JsonResource
{
    public function toArray($request)
    {
        return [
            'id' => $this->id,
            'uuid' => $this->salePoint->uuid,
            'code' => $this->code,
            'name' => $this->salePoint->name,
            'client_name' => $this->client_name,
            'business_name' => $this->salePoint->business_name,
            'longitude' => $this->salePoint->longitude,
            'latitude' => $this->salePoint->latitude,
            'format_id' => $this->format_id,
            'district_id' => $this->salePoint->district_id,
            'distributor_id' => $this->distributor_id,
            'sale_point_type_id' => $this->sale_point_type_id,
            'created_at' => $this->created_at,
            'updated_at' => $this->updated_at,
            'deleted_at' => $this->deleted_at
        ];
    }
}

What could cause this error all of a sudden?

Edit, it seems to be the amount of ids in the where in clause, right now it shows 2000 exactly, how can I chunk or split it up so it doesn't throw this error?

What is the right way to do something like this query without getting this error?

0 likes
7 replies
Tray2's avatar

A uuid is a string not an integer, so it need to be handled as such, and the limit of values in a IN is 999 (At least in Oracle, so probably similar in MySQL). However, you can use a subquery to fetch the ids, then you will not have that limit.

SELECT *
FROM t1
WHERE ti.id IN (SELECT t2.id 
			FROM t2)
eggplantSword's avatar

@Tray2 hmm how would I use that with eager loading? We went around the problem by adding an extra filter (that we probably should've had in the first place) to the query.

JussiMannisto's avatar

@Tray2 You can of course index UUIDs. They're just not going to have the same performance as incrementing keys.

I agree that most centralized apps are better off with incrementing keys, but for a lot of distributed apps UUIDs make more sense. So it really depends on their architecture.

eggplantSword's avatar

@Tray2 We originally had integer ids, but the problem we found was that since our system uses an app to create and manage items so we were having conflicts between ids, because someone would generate something on web and uses id = 10 but then someone on the app would also create something and get id = 10 so when we would try to upload stuff we would be getting a lot of duplicate primary key errors, so we decided to use uuids instead since they don't repeat.

Tray2's avatar

@JussiMannisto I wrote that you can't really index uuid. You can but it doesn't do much.

I also suggest the you change the ids to integers instead of uuid, since you can't really index uuids.

You can always display uuid, but use integers behind the scenes.

Tray2's avatar

@msslgomez The id should be generated by the database, not in you code. If you let the database handle the primary key, it will not matter where the request to create the record comes from. If you are using multiple database, then you might need to look at another solution.

Please or to participate in this conversation.