Надо сделать 103тыс запросов к базе

LazyBadger, вы сначала ответьте на

При всем уважении, я знаю что такое race conditions, но вашу фразу в упор понять не могу, что конкретно вы имели ввиду, в контексте баз данных и кеширования? И значит кроме отдельных race conditions?

SELECT COUNT(*) это для того, чтобы вы поняли что тут далеко не 2к артикулов как у тс, а в 1600 раз больше, я думал вы поймете что это не основной запрос, как минимум из плана выполнения, который я скинул))

Что рекомые рейсы могут наступить (и кэширование результатов будет нужно)… для этого только надо, чтобы поднятие "кэша" из базы было быстрее исполнения (сильно кучерявого) запроса на повторную выборку. Я такого представить не могу, ни на 2000 базе, ни на 2000000, но мне положено планировать в предположении "все случается".

Ферштейн?

Даром и по собственной инициативе я надеюсь не читать план запросов еще долго - я не живу так скучно, чтобы искать таких развлечений... но - перечитал не по диагонали, увидел. Не увидел обоснуя, что это будет так же по скорости, как с составными, а - только лишь цифры. И, между нами, 3+ миллионов строк - тоже не мощность

но кеш импакт не влияет на рейс если он не рекомый. а тогда как вы объясните кучерявость запроса? каждый рейс нужно кешировать чтобы он стал рекомый, иначе будет старвейшн, но смотрите чтоб не начался кеш компакшн. иначе без второй забивки, точно будет не разобрать. или как вариант побрить запрос, чтобы он стал лысый. аэродинамика лысой головы лучше. но это крайняя мера. это если скучно заживется.