Mysql 5.6 different execution plan for same query.(Java client vs terminal)

Question

The below query gives 2 different execution plan between GUI client (DB Viz) vs the terminal and taking too long when we call from GUI/Java apps.

-- When we execute the query from mysql terminal (directly on server from mysql client), the query runs in sub second. But when we call this query from Java apps/GUI client (Like DBVIz) it is taking 55 seconds.

-- Expected result is <10 rows.

-- We are using Mysql 5.6. All the table involved in this query are innodb.

-- The issue started with 5.6, we were using 5.0 and recently upgraded to 5.6.

-- Things to be noticed in this query is, this is joining 2 tables on the column that has different data type.

-- We have the similar problem on all the query that join based on the column "finer.refernce" this column is a varchar(255) column and it is a general purpose column which stores integer values and will be joined with other table which will have integer Ids.

-- We have the index idxf_reference on finer.refernce.

-- Note that the query has explicit type conversion CAST(lb.id AS CHAR). Tried the CONVERT(lb.id,CHAR(255)) also and same result.

-- The mysql driver used in GUI is mysql-connector-java-5.1.25. Also tried mysql-connector-java-5.1.31. and have the same problem.

-- Profiling on GUI shows the query took 52 seconds on "Sending data" state. and in terminal it is sub second for "Sending data"

-- The important different in the execution plan is, The GUI plan does not use the index and it uses "Using join buffer (Block Nested Loop)".

-- Tried FORCE INDEX and still not using index on GUI/Java apps.

-- Is this anything to do with BNL/BKA algorithms?

Query: ~~~~~~

SELECT ftc.display_name , fl.* FROM lpb lb INNER JOIN finer fl ON fl.reference = CAST(lb.id AS CHAR) LEFT JOIN fintran ftc ON fl.transactioncode_id = ftc.id WHERE lb.ld_id = 12345;

The plan had 3 rows, and 2 of them where identical, the difference is on the "fl" table. Below the extract of the plan.

Plan from GUI:

~~~~~~~~~~~~~~

id select_type table type possible_keys key key_len ref rows Extra

---

1 SIMPLE fl ALL (null) (null) (null) (null) 30100452 Using where; Using join buffer (Block Nested Loop)

Plan from Terminal:

~~~~~~~~~~~~~~~~~~~

+----+-------------+-------+--------+-----------------------------+-----------------------------+---------+------------------------------+------+-----------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+-----------------------------+-----------------------------+---------+------------------------------+------+-----------------------+ | 1 | SIMPLE | fl | ref | idxf_reference | idxf_reference | 258 | func | 1 | Using index condition |

+----+-------------+-------+--------+-----------------------------+-----------------------------+---------+------------------------------+------+-----------------------+

Answer 1

I found the reason for execution plan change, The server was not using the index while execute the query from GUI client due to utf8mb4 conversion needed on varchar column. This conversion needed because the j connector used in the java apps and GUI client is setting the below 2 variables as utf8mb4 based on the server configuration ( http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-13.html ).

character_set_client character_set_connection

and the table was in latin1. but, the terminal client is not using the j connector and it is keeping latin1 for the above 2 variables.

How we solved?.

The J connector is deciding the above value based on the server configuration, so we removed the below 2 from our server my.conf,

default-character-set = utf8 character-set-server = utf8

after remove this, by default the values set as latin1 and the issue solved. Hope this will help in future if somebody hit this same issue.