# Performance Impact of Optimization Methods on MySQL Document-Based and Relational Databases
## 5 Performance Tests--Results and Analysis
### Select Operation
#### 5.3.2 Select Using One Join  
A select operation that uses a single join is presented in Table 9. We consider that the business name field is unique because in the future, this field can be used to generate links to create sites for each business. We conducted a selection to obtain all users of this business, as presented in Table 9.  
In the case of using relational MySQL, users are obtained by performing a join based on the _business_id_ field, a field that is a foreign key in the user table, and then we set the condition that the business name is the one sought.  
In the case of document-based MySQL, users are obtained by searching for all businesses that have their respective name and a username which is not null. _DocResult_ contains a list of _DbDoc_ because it extends _FetchResult_<_DbDoc_>, returning an object that contains all the elements filtered according to the set conditions. Using the _deleted_ field, we exclude deleted items. As we have seen in the case of updates, in the case of selections, we must add the condition that the deleted field be null or false.  
Selecting the users of a business already involves using a join in relational MySQL, which automatically involves increasing the response times. Before applying the optimization methods, during the search, it must be checked that the element either has the field deleted null or deleted false. After optimization, with the addition of the index composed in the user table to _user_id_ and _business_id_, as well as the index in the deleted field, the search was much faster, the \"or\" disappeared, and each field that needed to be verified to comply with the conditions after \"where\" had an index, thus no longer scanning the entire tables.  
\begin{table}
\begin{tabular}{c} \hline \hline
**Relational MySQL: Select Using a Single Join Operation** \\ \hline @Query(value = “select u.* from business b inner join user u on b.id = u.business\_id \\ where b.name = “businessName and (b.deleted is null or b.deleted = false) \\ and (u.deleted is null or u.deleted = false)”, nativeQuery = true) \\ List+User\textgreater{} findByBusinessName(@Param(“businessName”) String businessName); \\ \hline
**Document-based MySQL: Select using a single join operation** \\ \hline DocResult res = collection.find(“name = “Beauty by Ali” and user.name is not null \\ and user.client.name is null”).execute(); \\ \hline \hline \end{tabular}
\end{table}
Table 9: Select operation using a single join.  
In the case of document-based MySQL, response times were much shorter than in the case of relational MySQL, the difference between these decreasing after applying the optimization methods, as can be seen in Figure 9.  
The indexes in document-based MySQL work on the same principle as in relational MySQL, helping to find the elements faster, having a huge impact in the case of relational MySQL. The optimization methods on the database structure and the fields do not have a significant impact; in this case, only the indexes bring significant improvements. After applying the optimization methods, relational MySQL significantly improved its response time, with the methods having a significant impact when the number of elements increased, as shown in Figure 9. After applying the optimization methods, relational MySQL was faster than document-based MySQL without optimizations; however, it had a lower performance than document-based MySQL with optimizations.