mysql 5.7 innodb_thread_concurrency расчет

Рекомендую переезжать на более современную SQL или последнюю MariaDB или MySQL8. Это чтобы быстрее работало всё.

А этот параметр лучше не трогать, ибо может снижаться производительность: https://www.percona.com/blog/2016/03/17/percona-server-5-7-performance-improvements/

Одна Pecrona что-то там сделала, чтобы у них этот параметр работал нормально, сама Mysql забила на него. Но 5.7 в любом случаи устарела.

Даже в старых темах: https://dba.stackexchange.com/questions/81204/hyperthreading-mysql-innodb-thread-concurrency-performance

Везде пишут, не трогать этот параметр. Никакой скорости он не прибавит.

Я лично не трогаю его и не настраиваю своим клиентам. 
Также и innodb_buffer_pool_instances не настраиваю. Он по умолчанию работает как надо.

При штатной, нормальной работы базы думаю по умолчанию подойдет innodb_thread_concurrency.

Но когда есть моменты кривых/тяжелых запросов, без ограничения innodb_thread_concurrency создаст узкие места процессора и диска.

Мое мнение.

Тесты тесты и ещё раз тесты. Какие могут быть места узкие если innoDB pool достаточный и диски SSD

Попробуем как нибудь по умолчанию innodb_thread_concurrency = 0.

При join выборок куча таблиц создается, а так же много joiun без индексно почему то используется.

Значит конструкция БД неудачная. И теперь надо или её переделывать или жить с этим. Кэши всякие там, разбивать на отдельные запросы без JOIN. 

Да вот же, руководству говорю что нужно избавляться от join запросов без индексных, это может снизить нагрузку сервера до 50%.

Но видать это дело затратное и руководство не спешит решать эту проблему.

В любом случаи  innodb_thread_concurrency  тут вообще никаким боком и не спасёт ситуацию.

Апгрейдить БД однозначно.
5.7 от 8.0 по "разумности" отличается очень сильно.
Тем более сейчас как бы 2021 на календаре, давно пора.
Несовместимостей минимум.

Попробуем обновить битрикс до последней версии стабильной, накатим php 8 / mysql 8.

После отпишусь.