Mysql 8.0.22 month() function and group by - mysql

I can't seem to figure out an underlying datatype issue (at least I think it is a datatype issue). Obviously writing here as I can't seem to put my finger on what is going wrong
Some background:
We have been trying to upgrade from mysql 5.7 to mysql 8.0.22 and I am tasked in checking database issues regarding inconsistencies. We fixed a timestamp datatype issue earlier in making sure both the times were in the same timezones and that seems to be in check. However, on mysql 8.0.22 I am facing a weird issue when grouping on this timestamp. Here is a small sample of the output that is eluding me:
The query essentially goes like
select year(date)
, month(date)
, *aggregation(a)*
, *aggregation(b)*
etc.
from blabla
join blabla
group by 1,2
It is just not making the month unique. I have a work around by using dateformat function however, I am just curious what might be causing this issue. This same query is working fine on my 5.7 db. I have checked that both databases are exact replicas in multiple ways. Any insight would be greatly appreciated.
Thank you!
edit As people wanted exact context as to what is going on. Here is a simplified query from the same table that shows the problem at hand.
edit no 2 I am adding the information schema and 10 rows for visibility of what the data looks like.
sample data:
schema:
Let me know if there is anything else you need to help me solve this. Apologies for the incomplete information. This part of database management/engineering or technical know how eludes me.
show create table results :
CREATE TABLE `order_status_history` (
`id` int NOT NULL AUTO_INCREMENT,
`order_id` int NOT NULL,
`admin_user_id` int NOT NULL,
`admin_user_name` varchar(255) NOT NULL,
`order_status` varchar(255) NOT NULL,
`date_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`o_type` enum('R','C','D') DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `indx_order_id` (`order_id`),
KEY `indx_order_status` (`order_status`),
KEY `indx_o_type` (`o_type`)
) ENGINE=InnoDB AUTO_INCREMENT=2375978 DEFAULT CHARSET=latin1

According to the MySQL 8.0 docs, the GETMONTH() function works with a date, not a timestamp. So you would need to do something like GETMONTH(FROM_UNIXTIME(date_update)) for your query to return expected results. What's interesting is that you said this was working in MySQL 5.7, but the docs for that function are identical to that found for 8.0. The one difference that your two installations might have is with the lc_time_names system variable, but this is just speculation.
A similar question was asked on this site about eight years ago, and the accepted answer is the same as I outlined above. 🤔

Related

Upgrading AWS RDS MySQL 5.7 to 8.0, failing at PrePatchCompatibility with false positive errors

I'm scratching my head off, but basically I'm upgrading my RDS instance from MySQL 5.7 to 8.0.
However, it's returning a very odd error during the PrePatchCompatibiity check.
12) Usage of removed functions
Following DB objects make use of functions that have been removed in version 8.0. Please make sure to update them to use supported alternatives before upgrade.
More Information:
https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals
app-website-org-staging.eav_value_point.value_point_value - COLUMN uses removed functions X (consider using ST_X instead), Y (consider using ST_Y instead)
The odd thing here is, I'm NOT using the functions X and Y on this stored generated column. I am ALREADY using ST_X and ST_Y in the generated column function. I was wondering how I can get rid of that error.
What I have tried:
In phpMyAdmin, edit, and save again.
In phpMyAdmin, edit, change the functions to uppercase, and save again.
Used mysqldump to export the table, and verified that indeed I was using ST_X and ST_Y.
Removed the problematic column.
1-3 did not work, 4 worked, but that was not my intention. I want to know the true reason.
Please see my table dump below:
CREATE TABLE `eav_value_point` (
`value_point_id` int(11) UNSIGNED NOT NULL,
`value_point_created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`value_point_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`value_point_modified_by` int(11) UNSIGNED DEFAULT NULL,
`value_point_attribute_id` int(11) UNSIGNED NOT NULL,
`value_point_entity_id` int(11) UNSIGNED NOT NULL,
`value_point_value_real` point NOT NULL,
`value_point_value` varchar(255) COLLATE utf8mb4_unicode_520_ci GENERATED ALWAYS AS (concat(st_x(`value_point_value_real`),',',st_y(`value_point_value_real`))) STORED
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
If anyone can shed me some light I'd appreciate it! Thanks all in advance!

Mysqldump fails on dumping virtual column

I have a largish (4GB) database, that I would like to dump, but when using the mysqldump tool (the MariaDB version, Ver 10.19 Distrib 10.4.21-MariaDB, for Linux (x86_64)), my dumping process has always failed at the same table, with the not so helpful error message:
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
I've tried to debug this error, but none of the obvious solutions worked for me, so I did a little experimenting, and found the culprit of my problem. The table in question, contains a VIRTUAL column, which strangely, if I remove, the dump finishes succesfully. I've digged a little more, but found no such error anywhere else relating to dumping MariaDB databases with virtual columns. Adding the --verbose option to the dump, is not helping either, as it gives me no other significant information.
As the query fails at the SHOW CREATE TABLE part, I've figured it has something to do with the structure of the CREATE TABLE query, but when I only try to dump the structure of this database, everything works like a charm. So I am stuck at the moment, trying to solve this issue. I could give up on the virtual column in this specific table, but if there would be any alternative, even a different dump tool, I would more likely go with that solution. Any advice, on how to fix this, or at least how to debug the problem more throughly would be appreciated!
Here are some other debug informations, that could be helpful:
This is the end of the --verbose dump output:
-- Retrieving view structure for table ActionLogReferences...
-- It's base table, skipped
-- Retrieving view structure for table ActionLogs...
-- It's base table, skipped
-- Retrieving view structure for table AffiliatePrograms...
-- It's base table, skipped
-- Retrieving view structure for table AffiliateProgramsCampaigns...
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
And here is the CREATE TABLE syntax for the table in question:
CREATE TABLE `AffiliateProgramsCampaigns` (
`AffiliateProgramsCampaignId` bigint(20) NOT NULL AUTO_INCREMENT,
`Name` varchar(255) NOT NULL,
`Description` tinytext NOT NULL,
`StartDate` datetime NOT NULL,
`EndDate` datetime NOT NULL,
`IsActivated` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'This column shows if this campaign was manually activated.',
`Status` tinyint(4) GENERATED ALWAYS AS (if(`IsActivated`,if(curdate() between `StartDate` and `EndDate`,1,0),0)) VIRTUAL COMMENT 'The final, computed status of the campaign. When querying, you should use this to check the status.',
`affiliatePrograms_AffiliateProgramId` mediumint(9) NOT NULL,
`images_ImageId_BaseImage` bigint(20) DEFAULT NULL COMMENT 'The id of the base image.',
`images_ImageId_CoverImage` bigint(20) DEFAULT NULL COMMENT 'The id of the cover image.',
PRIMARY KEY (`AffiliateProgramsCampaignId`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
The query that is reported by mysqldump btw runs every single time I try it, both from phpymadmin and from the command line mysql interface. I also tried dumping with different users, even with the root user, but I always get the same error, at the same spot.
The problem was with the CURDATE() function that was used in the virtual column. By changing the function, to CURRENT_TIMESTAMP(), the issue is solved.
Also posted a bug report on the official boards: https://jira.mariadb.org/browse/MDEV-26619

MySQL autoincrement column have diffrent behaviour with different databases

I have one working project in php and mysql.
In which I am using one column syntax for all my auto increment columns like below -
CREATE TABLE `mytable` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`sometext` int(11) NOT NULL
)
And for inserting records in this table in my whole proect I am using below syntax -
INSERT INTO mytable(ID,sometext)
VALUES(0,'Sometext')
And this is working fine.
But when I copied same DB and project and this code stopped working
So I changed my insert with below
INSERT INTO mytable( sometext)
VALUES( 'Sometext')
But this is very weird... In previous project old syntax is working fine but for new I have to make code change in 100 of places.
Can somebody tell me whats wrong with new MYSQL DB that it stopped supporting old syntax.
The difference is probably that your new database servers has the configuration option sql_mode=NO_AUTO_VALUE_ON_ZERO. Therefore only a NULL will cause an auto-increment to be generated.
Read https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html for full explanation of how sql modes affect your database server.
To avoid having to make code changes, you can change the server option.

How to deal with MySQL WorkBench bit(1) bug when it puts the 'b' literal before non-bit values?

Let's say I have a table 'day_attribute_type'
id bigint(20) AI PK
code varchar(255)
persist_date bigint(20)
update_date bigint(20)
active bit(1)
max int(11)
min int(11)
name varchar(255)
If I would add a new row into the Result Grid and press the Apply button, I would get the following query:
INSERT INTO `tl2`.`day_attribute_type` (`persist_date`, `update_date`, `active`, `max`, `min`, `name`)
VALUES ('1', '2', b'1', b'12', b'12', b'text');
It looks like Workbench puts 'b' not only before the bit field, but also before some other fields. It's really annoying to post-edit the query and remove their buggy things.
MySQL WorkBench 8.0.16 x64, Windows 10
MYSQL Community Server 8.8.12
I've updated MySQL Workbench for a year and this nasty bug continued to appear... I've even reinstalled my Windows.
It looks like nobody is going to fix it. It is mentioned here. Please, can somebody try to reproduce this bug on Linux/Max and confirm either you have it or not.
Tried this out myself (MySQL Workbench 8.0.19 on Windows) and saw the same results - agree it's pretty annoying.
As the issue hasn't been fixed in 4+ years I'd be tempted to use another MySQL GUI client for this purpose such as HeidiSQL, ToadSQL or DBeaver. Credit to JW-Munich for suggesting the last one in the comments.

"Cannot convert to a SELECT statement" What does this mean

I'm trying to make our mySQL database run faster and I've analyzed our slow query log and the most common slow query is this:
CREATE TABLE IF NOT EXISTS `wp_bad_behavior` (
`id` INT(11) NOT NULL auto_increment,
`ip` TEXT NOT NULL,
`date` DATETIME NOT NULL default '0000-00-00 00:00:00',
`request_method` TEXT NOT NULL,
`request_uri` TEXT NOT NULL,
`server_protocol` TEXT NOT NULL,
`http_headers` TEXT NOT NULL,
`user_agent` TEXT NOT NULL,
`request_entity` TEXT NOT NULL,
`key` TEXT NOT NULL,
INDEX (`ip`(15)),
INDEX (`user_agent`(10)),
PRIMARY KEY (`id`) );
I'm trying to understand why this query keeps getting called because after the table is setup it should not keep happening.
The EXPLAIN result for this is: Cannot convert to a SELECT statement.
Any ideas on this would be fantastic!
Paul
EXPLAIN will only work on SELECT queries, that's why it complains. As to why the query is in the slow query log: Either it is deleted and recreated - check the regular query log for DROP TABLEs - or it simply blocks because the table/database is busy - check the other slow queries first, especially the ones on the same table.
Of course you can't convert a CREATE statement to a SELECT statement...
The question therefore is, why a creation statement is called so frequently. It uses mysql's IF NOT EXISTS, so it might not even be a design issue, the table would only get created once despite the query is called bazillion times. Maybe your system that uses the database issues this statement from every single method, as a way to make sure actual database structure matches its expectations. Just a foolprof in case somebody deletes this super important table.
Its probably there as an easy way to recover from someone deleting the table. A good reason why someone would delete the table is that it's an easy way to get rid of old log files. However this obviously affects performance and so you should check that none of the code is deleting the table and then remove this check. Then you will be required to manually recreate the table when deleting old logs.