Mysql: Is it possible to handle 1000 concurrent while having low cpu?
Here's how to identify which 'bad' query to fix that will give you the most bang for the buck:  The slowlog plus pt-query-digest.  More details here:  http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog

I rarely need to go down the list more than 3 items to make a dramatic improvement.

If you are weak on knowing what indexes to add, don't simply "index ever column".  See http://mysql.rjweb.org/doc.php/index_cookbook_mysql


  Is there any measure one could take that I didn't know about to reduce the CPU usage of search queries?


No.  High CPU is fixed by using selected composite indexes and/or reformulating the queries.  Show us the queries.  "Search" is too vague a term.

Here's an extreme anecdote:  The CPU was pegged at 100%.  The slowlog pointed at one query.  It had WHERE DATE(foo) = '...'.  By making that "sargable", the CPU dropped to 2%.

As for benchmarks...  Beware.  They tend to see how many connections they can run before running out of horsepower.  That is, the results are guaranteed to say 100% CPU!  The real metric they get out is "queries/second" or "maximum connections".

Furthermore, it has repeatedly been documented that if you push mysql beyond some number of concurrent users, throughput goes down!  A decade ago, that number was about 6; now it is more like 64.  But 1000?  No way.  It is spinning its wheels because all 1000 are stumbling over each other.

How to handle 1000 users?  Replication feeding multiple Slaves.  With such, you could have 1000 slaves, each running a mere 10 connections; CPU will be very low.  Etc.