EverSQL Database Performance Knowledge Base

The optimization process and recommendations:

1. Avoid Calling Functions With Indexed Columns (query line: 14): When a function is used directly on an indexed column, the database's optimizer won’t be able to use the index. For example, if the column `code` is indexed, the index won’t be used as it’s wrapped with the function `CONCAT`. If you can’t find an alternative condition that won’t use a function call, a possible solution is to store the required value in a new indexed column.
2. Avoid Calling Functions With Indexed Columns (query line: 15): When a function is used directly on an indexed column, the database's optimizer won’t be able to use the index. For example, if the column `ValueCode` is indexed, the index won’t be used as it’s wrapped with the function `CONCAT`. If you can’t find an alternative condition that won’t use a function call, a possible solution is to store the required value in a new indexed column.
3. Avoid LIKE Searches With Leading Wildcard (query line: 14): The database will not use an index when using like searches with a leading wildcard (e.g. '%'). Although it's not always a satisfactory solution, please consider using prefix-match LIKE patterns (e.g. 'TERM%').
4. Avoid LIKE Searches With Leading Wildcard (query line: 15): The database will not use an index when using like searches with a leading wildcard (e.g. '%'). Although it's not always a satisfactory solution, please consider using prefix-match LIKE patterns (e.g. 'TERM%').
5. Avoid Selecting Unnecessary Columns (query line: 2): Avoid selecting all columns with the '*' wildcard, unless you intend to use them all. Selecting redundant columns may result in unnecessary performance degradation.
6. Avoid Selecting Unnecessary Columns (query line: 6): Avoid selecting all columns with the '*' wildcard, unless you intend to use them all. Selecting redundant columns may result in unnecessary performance degradation.
7. Avoid Subqueries (query line: 5): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
8. Create Optimal Indexes (modified query below): The recommended indexes are an integral part of this optimization effort and should be created before testing the execution duration of the optimized query.
9. Explicitly ORDER BY After GROUP BY (modified query below): By default, the database sorts all 'GROUP BY col1, col2, ...' queries as if you specified 'ORDER BY col1, col2, ...' in the query as well. If a query includes a GROUP BY clause but you want to avoid the overhead of sorting the result, you can suppress sorting by specifying 'ORDER BY NULL'.

Optimal indexes for this query:

ALTER TABLE `ParametrickeVyhladavanie` ADD INDEX `parametrickevyhlad_idx_code` (`code`);
ALTER TABLE `produkty` ADD INDEX `produkty_idx_kategoria` (`KATEGORIA`);

The optimized query:

SELECT
        pa.* 
    FROM
        ParametrickeVyhladavanie pa,
        (SELECT
            p.* 
        FROM
            produkty p 
        WHERE
            p.KATEGORIA IN (
                '$categoryArray'
            )) produkt 
    WHERE
        produkt.ATTRIBUTE_CODE LIKE CONCAT('%', pa.code, '%') 
        AND produkt.ATTRIBUTE_VALUE LIKE CONCAT('%', pa.ValueCode, '%') 
    GROUP BY
        pa.code 
    ORDER BY
        NULL