ステートメント内の5000以上のバインドプレースホルダーではなく、返される行数である行のフェッチが遅いのではないかと思います。 pId IN ( ? , ? , ... , ? )
私の提案は、単一の行のみを返すことをテストし、存在することがわかっている1つの値を指定するか、行を返すことです。次に、存在しないことがわかっている/行を返さない4999以上の値を指定します。
たとえば、テーブルで最大のpId値がわかっている場合は、それよりも高い値を使用し、次のようなステートメントにバインド値を指定します
... pId IN ( ? , ? , ? , ... , ? )
したがって、結果は実行と同等になります
... pId IN ( 99999999 , 99999998 , 99999997 , ... , 42 )
これは、実行するのと同じ結果になります
... pId IN ( 42 )
私たちの期待は、1行だけを返すことです（pId =42）。
次に、そのタイミング（5000以上のバインド値が1行を返す）を2つのバインド値が1行を返すタイミングと比較します
... pId IN ( 99999999 , 42 )
そして、パフォーマンスに大きな違いがあるかどうかを確認してください。
（5000以上のバインド値を処理する作業はまだありますが、巨大なとは思わないでしょう。 違いはありますが、テストする必要があります。
少し考えてみると、既存のすべてのバインド値を使用して、LIMIT 2を追加するだけでテストを設定する方が簡単かもしれません。 クエリの最後まで。 （MySQLにLIMIT 2のパフォーマンスが強化されているかどうかはわかりません 。
AND pId * 10 = 420のような条件を追加する方が良いかもしれません
目標は、多数のバインド値を提供することですが、1行または2行のみを返します。
もう1つのテストは、多数の行全体を返すことですが、いくつかのバインド値のみを使用します。おそらく5000行以上を返す範囲条件です。
クエリは次のようになります：
... pId >= ? AND pId <= ?
提供された値の間の範囲が十分に広く、5000行付近になります。
そして、パフォーマンスを比較します。
私の予測（推測？）は、パフォーマンスはバインド値の数ではなく、返される行の数とより相関するということです。
これがあなたの質問に対する答えかどうかはわかりませんが、質問に答えるために私が取るアプローチです...「これが遅くなる原因、バインド値の数、または返される行の数は何ですか？ "