I have 3 MySQL/MariaDB servers running for application development and testing:
MySQL Community Server 5.7.32
MySQL Community Server 8.0.16
MariaDB Community Server 10.4.12
The servers are configured to run on different ports on the same machine.
SELECT ##sql_mode for all servers:
MySQL Community Server 5.7.32: NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
MySQL Community Server 8.0.16: STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
MariaDB Community Server 10.4.12: NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION
I stumbled across some SELECT queries in old code I maintain whose fails to run, for e.g. searching a date with a given pattern. The queries look like this:
SELECT * FROM `userTable` WHERE `birthDate` LIKE '2020-%-%';
SELECT * FROM `userTable` WHERE `birthDate` LIKE '%12%';
The table looks like this:
CREATE TABLE IF NOT EXISTS `userTable` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` TEXT COLLATE utf8_unicode_ci,
`birthDate` DATE,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
When I run the queries on MySQL Community Server 8.0.16 they fail with the error Error Code: 1525. Incorrect DATE value: '2020-%-%'. and Error Code: 1525. Incorrect DATE value: '%12%'..
MySQL Community Server 5.7.32 and MariaDB Community Server 10.4.12 executes the queries successfully.
Why does MySQL Community Server 8.0.16 fails to execute these SELECT queries?
PS: The first SELECT query can be written as
SELECT * FROM `userTable` WHERE YEAR(`birthDate`) = 2020;
to run on all 3 servers.
EDIT: It's a bug in MySQL Community Server 8.0.16 and fixed in version 8.0.22.
You should be comparing a bona fide date column against valid date literals, not strings, e.g. to find records in 2020:
SELECT *
FROM userTable
WHERE birthDate >= '2020-01-01' AND birthDate < '2021-01-01'; -- sargable :-)
Or maybe:
SELECT *
FROM userTable
WHERE YEAR(birthDate) = 2020; -- not sargable though :-(
Related
I'm replicating from mysql 5.6.33 to 5.7.41. I have a table with a datetime field. If I understand correctly, between 5.6 and 5.7 the decreased the space a datetime field uses because it doesn't store timezone data. (but a timestamp does).
This query works on 5.7 (note the presence of the timezone field):
select count(*) from login_activities where date_created < '2023-01-15 04:00:15 -0800';
This delete statement does not work:
delete from login_activities where date_created < '2023-01-15 04:00:15 -0800'
ERROR:
Error 'Incorrect datetime value: '2023-01-15 04:00:15 -0800' for column 'date_created' at row 1' on query. Default database: 'sms'. Query: 'delete from login_activities where date_created < '2023-01-15 04:00:15 -0800''
How can I get the delete to work in the same way the select works? I've even removed sql_mode entries but still can't get it to work in 5.7
edit:
not sure if this matters, but the error with the delete statement is happining during replication (5.6 -> 5.7), but I'm running the select statement manually. I haven't tried running the delete statement manually because it will through off the replication.
Its error when I send a query to mysql from clickhouse server.
Mysql can't understand query like
SELECT /*+ MAX_EXECUTION_TIME(1000) */ column1, column2
from mysql_tables.table1
from clickhouse through a table created with the mysql engine.
How to correctly enter the MAX_EXECUTION_TIME() constraint? to the mysql engine when creating a table like
CREATE TABLE mysql_tables.table1
(
`id` Int32,
`status` Int32
)
ENGINE = MySQL('host',
'db',
'table1',
'user',
'password',
)
SETTINGS [MAX_EXECUTION_TIME=1000]
or to the query itself?
Unfortunately, you can't pass comment to MySQL
According to
https://clickhouse.com/docs/en/engines/table-engines/integrations/mysql/#read-write-timeout
you can set up SETTINGS read_write_timeout=XXX
Unfortunately, this is not max execution time, and query still run on MySQL side
but if you will use ProxySQL, and setup default_query_timeout
https://proxysql.com/documentation/global-variables/mysql-variables/
it could work
I'm trying to run this query:
SELECT wins FROM players WHERE auth = '[U:1:123456789]' LIMIT 1;
But I get the following error:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'LIMIT 0, 25' at line 1
However, when I remove LIMIT 1 it works.
If I change the query to look like this, it also works:
SELECT wins FROM players WHERE auth = '[123456789]' LIMIT 1;
I'm very confused, what am I doing wrong? It seems like colons just break the query.
Edit: CREATE TABLE
CREATE TABLE `players` (
`auth` varchar(32) NOT NULL,
`name` varchar(32) NOT NULL DEFAULT '< blank >',
`wins` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`auth`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
Three Four options (starting with the most likely):
0) Your version of your SQL Database or your version of PHPMyAdmin is very, very out of date and should be updated ASAP.
1) You're running the SQL on a PHP PDO interface which uses Colons to mark an input variable. See here.
2) MariaDb uses colons as special characters and they need to be properly escaped.
3) Somehow you have two LIMITs (as mentoned by Tadman, that PhpMyAdmin or your own PHP interface is adding a LIMIT) when one is not needed.
It ended up being an issue with phpMyAdmin's (the client I used to run the queryh) SQL parser.
As of 4.7.1 of phpMyAdmin, it should be fixed.
https://github.com/phpmyadmin/sql-parser/commit/4f85b6d8d3a3ddcf6ff216c116cf305978e9a3d2
I have install mysql server version 5.7.9 but mysql json functions not working like jsn_length(),jsn_merge()..etc.
I have created a table with one field.
CREATE TABLE t1 (
jdoc json DEFAULT NULL
)
ENGINE=InnoDB DEFAULT CHARSET=latin1;
After insert data in this field with json format:
"{"name": "pankaj", "lname": "kumar"}"
then I execute this query
select jsn_length(jdoc) from t1
I am getting this type error in phpmyadmin:
MySQL said: Documentation
1305 - FUNCTION jsn_length does not exist
I think your problem is syntax related.
Instead of :
select jsn_length(jdoc) from t1
Run :
select JSON_LENGTH(jdoc) from t1
The query listed below is running fine on localhost but it's somehow hanging when executed remotely targeting my service provider database (both the PHP script and the SQL query in the phpMyAdmin console hang), although every chunk is returning the expected table when run individually.
What's wrong? Any suggestions on how to make it shorter or simpler and thus help the remote MySQL?
SELECT * FROM `Table1`
WHERE `Tag1` IN (
SELECT DISTINCT `Tag1` FROM `Table2`
WHERE `Tag1` NOT IN (
SELECT `Tag1` FROM `Table2` WHERE `Tag2` = '$keyWord'
)
)