In our last lesson, we looked at how using a WHERE IN subquery can be much faster than using a WHERE HAS or even a JOIN. Using a WHERE IN allowed our query to start using the company name index, which had a noticeable improvement on our overall query. However, it still wasn't enough to get the query to use our first name and last name indexes on the users table. In this lesson, we're going to look at a somewhat radical approach to solving this problem. We're going to intentionally run multiple database queries. By running multiple queries, we can simplify and isolate each individual query, allowing the query planner to run them in the most performant way. Let's start by copying our current query and doing some testing in TablePlus. The first thing I want to try is just running the company subquery all on its own. As you can see, we're getting company ID 1000 back. Also, notice how fast this query is. It ran in less than one millisecond.

As you can see, we're getting companyId 1000 back. Also, notice how fast this query is. It ran in less than one millisecond. Plus, if we run an EXPLAIN on it, we can see it's using the companyName index. So on its own, this query runs very efficiently. Let's update our main query to use this computed value instead of running the company subquery. We'll remove the subquery entirely from the first two keywords since there's no company matches for them anyway. And then for the Microsoft keyword, let's replace the subquery with a precomputed companyId of 1000. Now let's run the query. It just ran in less than one millisecond. Let's add an EXPLAIN to see what happened. And voila! Our query is now using our userFirstName and userLastName indexes.

Let's add an EXPLAIN to see what happened. And voila! Our query is now using our user firstName and user lastName indexes. Both of these queries individually ran in less than one millisecond and combined they're just over one millisecond. That's a huge drop from where we were at. And that's entirely because both of our queries, now running in isolation, are able to use the indexes we created. Okay, let's make the same change in our app. What we're going to do is just remove this subquery and run a query inline here instead. Company::query() where the name is like our search term. And then we'll just pluck the ID because that's all we need. Now let's view this in the browser.

And then we'll just pluck the ID because that's all we need. Now let's view this in the browser. As you can see we're at about 95 milliseconds right now. Let's hit refresh. We're now at 3.93 milliseconds. Amazing! And as you can see, we've now introduced three new queries. A Company query for each one of our search terms. However, if we look here, we can see that every one of our queries is running really, really fast. Which is why our total combined query time is only 3.93 milliseconds.