In the process of upgrading from MySQL 5.6 to 5.7 on RDS I'm finding differences in results returned for a number of queries.
For instance (table names obfuscated):
SELECT `model_s`.`id`,`model_s`.`pr`,`model_s`.`o_id`,`model_s`.`uploadee`
,`model_s`.`created_at`,`model_s`.`updated_at`,`model_s`.`o_ref`,`model_s`.`i_ref`
,`model_s`.`stss`,`model_s`.`u_fol`,`model_s`.`sdd`,`model_s`.`an_t_id`,`model_s`.`rean`
,`model_s`.`dpp`,`model_s`.`bg_t_cr`
FROM `model_s`
INNER JOIN `o_o` ON (`model_s`.`o_id` = `o_o`.`id`)
WHERE (
`model_s`.`pr` IN
(
SELECT u0.`id` AS col1
FROM `pr_pr` u0
LEFT OUTER JOIN `pr_stfr_pr_p` u1 ON (u0.`id` = u1.`pr`)
LEFT OUTER JOIN `acc_strf` u2 ON (u1.`stfr_id` = u2.`id`)
LEFT OUTER JOIN `acc_us_strf_as` u3 ON (u2.`id` = u3.`stfr_id`)
LEFT OUTER JOIN `pr_us_pr_p` u5 ON (u0.`id` = u5.`pr`)
WHERE (u3.`usr` = 7 OR u5.`usr` = 7)
)
AND NOT (`model_s`.`stss` = d)
AND `o_o`.`name` LIKE %my text%
)
ORDER BY `model_s`.`created_at` DESC
In this case, 5.6 returns 1 result and 5.7 returns 2 results (the latter being the expected behaviour).
Options for the DB are merely the default RDS 5.6 and 5.7 options (none changed at all).
Any idea why with default options we see such a difference between 5.6 and 5.7? (Please, no comments on complexity/readability/optimization of the query - its generated by the Django ORM and is a question for the future...)
Related
I am trying to debug 'innodb lock waits' according to this manual. It suggests that I visualise debugging info using query
use performance_schema;
SELECT THREAD_ID,EVENT_ID,EVENT_NAME,CURRENT_SCHEMA,SQL_TEXT FROM events_statements_history_long
WHERE THREAD_ID IN (SELECT BLOCKING_THREAD_ID FROM data_lock_waits) ORDER BY EVENT_ID')
However data_lock_waits is present in MySQL > 5.7 while I have MySQL = 5.7. Tutorial suggests that I look into information_schema.INNODB_LOCK_WAITS. However, this table has the following columns: requesting_trx_id requested_lock_id blocking_trx_id blocking_lock_id.
How I can translate blocking_trx_id into Blocking Thread Id in MySQL 5.7?
Apparently it is this request:
SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b
ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r
ON r.trx_id = w.requesting_trx_id;
https://dev.mysql.com/doc/refman/5.6/en/innodb-information-schema-examples.html
I have a laravel application that was running an elqouent query with a whereHas method. The method was not returning any data on a virtual machine running mysql 5.7 but was working on 5.6. I got the raw query out of eloquent, here's what it is:
select * from `threads` where `id` = 5053 and exists (select * from `users` inner join `threads_users` on `users`.`id` = `threads_users`.`user_id` where `threads_users`.`thread_id` = `threads`.`id` and `user_id` = 296) limit 1
When I run this sql in mysql 5.6 it will return a single row but when I run it on mysql 5.7 it returns nothing. Is there some feature that was removed between these versions that would break this query?
For a projet, I retrieved the database from a client. This database contains tables that have attributes composed by several words that are concatenated separated by a point. exemple :
table A : id, number.client , global.score
table B : id, favorite.style
So when I do a sql request on this tables to filter to filter the results according to number.client for exemple, I have an error returned by MySQL.
For exemple I have this request :
SELECT * FROM A
INNER JOIN B
ON (A.ref_track = B.id)
INNER JOIN C
ON (C.id = B.ref_plannode)
WHERE (B.id= 1)
AND (A.number.client > 50)
ORDER BY A.id DESC
When I run this request I get this error :
MySQL replied:
#1064 - Syntax error on A.number.client > 50
I think that MySql don't failed when we have an attribute composed by servel words separated by point ( like number.client). So what is the solution ??
For inforamtion this database is out of my responsibility, I got it from a client!!.
You have to quote the columns names with "`"
SELECT *
FROM A
JOIN B
ON A.ref_track = B.id
JOIN C
ON C.id = B.ref_plannode
WHERE B.id= 1
AND A.`number.client` > 50
ORDER BY A.id DESC
Edit
Working example
Is the same case that white spaces, you can use this:
SELECT * FROM A
INNER JOIN B
ON (A.ref_track = B.id)
INNER JOIN C
ON (C.id = B.ref_plannode)
WHERE (B.id= 1)
AND (A.`number.client` > 50)
ORDER BY A.id DESC
The MySQL can use diferent quotes or braquets, depends of configuration.
The MySQL server can operate in different SQL modes, and can apply these modes differently for different clients, depending on the value of the sql_mode system variable.
You can view the configuration with this command:
SELECT ##GLOBAL.sql_mode;
SELECT ##SESSION.sql_mode;
And you can know more about the configuration of mysql here https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_ansi_quotes
Try to quote the column name putting it between square brackets.
So
AND (A.[number.client] > 50)
I have a query that is returning two different results from two MySql servers i'm running.
This is the query (generated by Entity Framework, I run it directly in MySql to ensure the results are coming back from each server differently):
SELECT
CASE WHEN Project1.C1 IS NULL THEN '5' ELSE Project1.data_entered END AS C1
FROM ( SELECT 1 AS X) AS SingleRowTable1
LEFT OUTER JOIN (SELECT
Extent1.data_entered,
1 AS C1
FROM rta_option_data AS Extent1
INNER JOIN rta_option_field AS Extent2 ON Extent1.rta_option_field_id = Extent2.rta_option_field_id
WHERE (Extent1.customer_id = 1546) AND (Extent2.Name = 'txtAdverseDelay') ) AS Project1 ON 1 = 1
Server A is running MySql 5.5.28 and returns 5 which is the correct and expected value.
Server B is running MySql 5.7.12-log and returns null which is the incorrect and unexpected value.
I'm at a complete loss of how to resolve this, I was planning a server upgrade this weekend but i'm super worried about other similar queries that could be impacted by this.
Additional notes:
They are both using the exact same data.
When I run the inner query on both servers they return the same results data_entered = null and C1 = null. This is the inner query i'm talking about:
SELECT
Extent1.data_entered,
1 AS C1
FROM rta_option_data AS Extent1
INNER JOIN rta_option_field AS Extent2 ON Extent1.rta_option_field_id = Extent2.rta_option_field_id
WHERE (Extent1.customer_id = 1546) AND (Extent2.Name = 'txtAdverseDelay')
Would appreciate any guidance/advice on how to possibly fix this - not sure if there is a setting in MySql or what.
hey, i have 2 version of mysql on windows 5.1.39-community and on linux 5.1.39-log
i execute a query:
SELECT `o`.`idOffer`,
`o`.`offer_date`,
`p`.`factory`,
`c`.`short` AS `company`,
`s`.`name` AS `subcategory`,
`ct`.`name` AS `category`,
count( (select count(1) from product where idProduct=idOffer group by idOffer) ) as b
FROM `Offer` AS `o`
LEFT JOIN `Product` AS `p` ON o.idOffer = p.idOffer
LEFT JOIN `company` AS `c` ON o.company = c.id
LEFT JOIN `Subcategory` AS `s` ON s.idSubcategory = o.idSubcategory
LEFT JOIN `Category` AS `ct` ON ct.idCategory = s.idCategory
WHERE (o.idOffer = p.idOffer) GROUP BY `o`.`idOffer`
on windows it works as it suppose, but on linux it says:
ERROR 1242 (21000): Subquery returns more than 1 row
is it any way to get it worked on linux without any mysql updates/downgrades ?
Since your SQL "as b" columnResult is based specifically on a SQL, and the WHERE clause of the of the idOffer already qualifies and SHOULD be the same, I would remove the group by of this columnar element. I can only assume there might be some white-space data or other that is falsely getting included and "ID1" is different than "ID1 " is getting falsely interpretted.
No idea if this has anything to do with it, but Linux MySQL tables are case sensitive while Windows tables are not (because of the filesystem, I suspect), anyway, you have Product and product and that will cause some problems.
Don't know if it really is the cause of the problem in your question, but it is a wall you may end up flying smack into and I thought it should be brought up.