MySQL迁移至GreatSQL后,timestamp字段插入报错解析

SpringBoot+Vue+MySQL 高校学科竞赛平台 完整可运行版(源码+文档) 本项目基于SpringBoot+Vue+MySQL构建高校学科竞赛管理平台,覆盖学生、教师、领队教师、管理员四大角色,实现竞赛发布、报名、刷题、评分、公示等全流程闭环管理。系统架构清晰,技术主流,配套完整源码、数据库脚本、万字论文、开题报告、答辩PPT及部署文档,支持一键运行,适用于毕业设计、课程设计及院系二次开发,真正实现“开箱即用”。 阅读详情

MySQL迁移至GreatSQL后,timestamp字段插入报错解析

背景描述

某业务系统进行国产化适配,将MySQL的数据迁移到 GreatSQL 后,执行 INSERT INTO ,update_time传参为空时报错,报错信息为:ERROR 1048 (23000): Column ‘update_time’ cannot be null ,而原来旧的MySQL环境中没有这个问题。

greatsql> INSERT INTO `t_interface` 
(`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
ERROR 1048 (23000): Column 'update_time' cannot be null 

问题分析

1、在 GreatSQL 进行复现

CREATE TABLE `t_interface` (
  `interfacer_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `user_id` int(11) NOT NULL COMMENT '用户id(部门接口人)',
  `department_id` int(11) NOT NULL COMMENT '部门id',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `remark` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `is_deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除(0未删除 1已删除)',
  PRIMARY KEY (`interfacer_id`) USING BTREE,
  KEY `user_id` (`user_id`) USING BTREE,
  KEY `department_id` (`department_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1162 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;


INSERT INTO `t_interface` 
(`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);

greatsql> INSERT INTO `t_interface` 
      (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
ERROR 1048 (23000): Column 'update_time' cannot be null

在 GreatSQL 中,INSERT 语句确实报错了。

2、在MySQL 8.0.32中进行复现

mysql> SELECT  version();
+-----------+
| version() |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> CREATE TABLE `t_interface` (
    ->   `interfacer_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
    ->   `user_id` int(11) NOT NULL COMMENT '用户id(部门接口人)',
    ->   `department_id` int(11) NOT NULL COMMENT '部门id',
    ->   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    ->   `remark` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
    ->   `is_deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除(0未删除 1已删除)',
    ->   PRIMARY KEY (`interfacer_id`) USING BTREE,
    ->   KEY `user_id` (`user_id`) USING BTREE,
    ->   KEY `department_id` (`department_id`) USING BTREE
    -> ) ENGINE=InnoDB AUTO_INCREMENT=1162 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;
INSERT INTO `t_interface` 
Query OK, 0 rows affected, 7 warnings (0.04 sec)


mysql> INSERT INTO `t_interface` 
    -> (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
ERROR 1048 (23000): Column 'update_time' cannot be null

在MySQL 8.0.32中,INSERT 语句也报错了。

3、在MySQL 5.7.30中进行复现

mysql> SELECT  version();
+------------+
| version()  |
+------------+
| 5.7.30-log |
+------------+
1 row in set (0.00 sec)
mysql> CREATE TABLE `t_interface` (
    ->   `interfacer_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
    ->   `user_id` int(11) NOT NULL COMMENT '用户id(部门接口人)',
    ->   `department_id` int(11) NOT NULL COMMENT '部门id',
    ->   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    ->   `remark` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
    ->   `is_deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除(0未删除 1已删除)',
    ->   PRIMARY KEY (`interfacer_id`) USING BTREE,
    ->   KEY `user_id` (`user_id`) USING BTREE,
    ->   KEY `department_id` (`department_id`) USING BTREE
    -> ) ENGINE=InnoDB AUTO_INCREMENT=1162 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO `t_interface` 
    -> (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT   * from t_interface;
+---------------+---------+---------------+---------------------+--------+------------+
| interfacer_id | user_id | department_id | update_time         | remark | is_deleted |
+---------------+---------+---------------+---------------------+--------+------------+
|          1162 |       9 |            18 | 2025-07-08 10:34:43 | NULL   |          0 |
+---------------+---------+---------------+---------------------+--------+------------+
1 row in set (0.00 sec)

在 MySQL 5.7.30 中,INSERT 语句可以正常执行。

4、问题排查

查看表的字段定义:

update_time:timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’

建表语句里update_time字段类型为timestamp,NOT NULL的限制,默认值为 CURRENT_TIMESTAMP。

字段有 NOT NULL 的限制,不让插入NULL值,理论上是正确的。但 MySQL 5.7 为什么能插入成功呢?

查询系统timestamp相关的系统参数

mysql> SELECT  version();
+------------+
| version()  |
+------------+
| 5.7.30-log |
+------------+
1 row in set (0.00 sec)

mysql>SHOW  variables LIKE '%timestamp%';
+---------------------------------+-------------------+
| Variable_name                   | Value             |
+---------------------------------+-------------------+
| explicit_defaults_for_timestamp | OFF               |
| log_timestamps                  | SYSTEM            |
| timestamp                       | 1751270610.230160 |
+---------------------------------+-------------------+
3 rows in set (0.01 sec) 

mysql> SELECT VERSION();
+-----------+
| VERSION() |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> SHOW variables like '%timestamp%';
+---------------------------------+-------------------+
| Variable_name                   | Value             |
+---------------------------------+-------------------+
| explicit_defaults_for_timestamp | ON                |
| log_timestamps                  | SYSTEM            |
| original_commit_timestamp       | 36028797018963968 |
| timestamp                       | 1751270143.113409 |
+---------------------------------+-------------------+
4 rows in set (0.01 sec)


greatsql>SELECT  version();
+-----------+
| version() |
+-----------+
| 8.0.32-26 |
+-----------+
1 row in set (0.00 sec)

greatsql>SHOW variables like '%timestamp%';
+---------------------------------+-------------------+
| Variable_name                   | Value             |
+---------------------------------+-------------------+
| explicit_defaults_for_timestamp | ON                |
| log_timestamps                  | SYSTEM            |
| original_commit_timestamp       | 36028797018963968 |
| timestamp                       | 1751271661.160386 |
+---------------------------------+-------------------+
4 rows in set (0.02 sec)

可以看到在MySQL 5.7中 explicit_defaults_for_timestamp =OFF,

在MySQL 8.0.32和 GreatSQL 中 explicit_defaults_for_timestamp =ON

greatsql>INSERT INTO `t_interface` 
    -> (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
ERROR 1048 (23000): Column 'update_time' cannot be null
greatsql>set explicit_defaults_for_timestamp=OFF;
Query OK, 0 rows affected, 1 warning (0.00 sec)

greatsql>INSERT INTO `t_interface`  (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, null, 0);
Query OK, 1 row affected (0.00 sec)

在greatsql中,设置explicit_defaults_for_timestamp =OFF后,INSERT 语句可以正常执行。

5、参数说明

explicit_defaults_for_timestamp 这个系统变量决定服务器是否为TIMESTAMP列中的默认值和 空值处理启用某些非标准行为。 默认情况下,MySQL5.7禁用explicit_defaults_for_timestamp, 它启用非标准行为。MySQL8.启用explicit_defaults_for_timestamp,禁用非标准行为。

如果explicit_defaults_for_timestamp被禁用,服务器将启用非标准行为并按如下方式处理TIMESTAMP列:

1、未显式声明NULL属性的TIMESTAMP列将自动声明not NULL属性。允许将这样的列赋值为NULL,并将列设置为当前时间戳。

2、表中的第一个TIMESTAMP列,如果没有显式地使用NULL属性或显式地使用DEFAULT或ON UPDATE属性声明,则会自动使用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP属性声明。

3、第一个之后的TIMESTAMP列,如果没有显式地使用NULL属性或显式的DEFAULT属性声明,将自动声明为DEFAULT ‘0000-00-00 00:00:00’(“零”时间戳)。对于没有为这样的列指定显式值的插入行,将为该列分配‘0000-00-00 00:00:00’,并且不会出现警告。

4、根据是否启用了strict SQL模式或NO_ZERO_DATE SQL模式,默认值’0000-00-00 00:00:00’可能无效。请注意,TRADITIONAL SQL模式包括严格模式和NO_ZERO_DATE。

非标准行为在MySQL的未来版本中会被删除。

如果启用了explicit_defaults_for_timestamp,服务器将禁用非标准行为并按如下方式处理TIMESTAMP列:

1、不会将TIMESTAMP NULL列设置为当前时间戳。要分配当前时间戳,请将列设置为CURRENT_TIMESTAMP或NOW()之类的同义词。

2、未显式声明not NULL属性的TIMESTAMP列将自动声明NULL属性并允许NULL值。将这样的列赋值为NULL将其设置为NULL,而不是当前的时间戳。

3、用NOT NULL属性声明的TIMESTAMP列不允许NULL值。对于为这样的列指定NULL的插入,如果启用了严格的SQL模式,则结果是单行插入错误,如果禁用了严格的SQL模式,则会插入’0000-00-00 00:00:00’。在任何情况下,将列赋值为NULL都不会将其设置为当前时间戳。

4、使用NOT NULL属性显式声明且没有显式DEFAULT属性的TIMESTAMP列被视为没有默认值。对于没有为这样的列指定显式值的插入行,结果取决于SQL模式。如果启用了严格SQL模式,则会出现错误。如果没有启用严格的SQL模式,则使用隐式默认值’0000-00-00 00:00:00’声明列,并出现警告。这类似于MySQL处理其他时间类型(如DATETIME)的方式。

5、没有时间戳列被自动声明为默认的CURRENT_TIMESTAMP或ON UPDATE CURRENT_TIMESTAMP属性。这些属性必须显式指定。

6、表中的第一个TIMESTAMP列与第一个后面的TIMESTAMP列的处理方式没有区别。

greatsql>SET explicit_defaults_for_timestamp=OFF;
Query OK, 0 rows affected, 1 warning (0.00 sec)
greatsql>CREATE TABLE t1( time1 timestamp, time2 timestamp null, time3 timestamp default '2025-01-01 00:00:00', name varchar(100) );
Query OK, 0 rows affected (0.03 sec)
greatsql>INSERT INTO t1  (`time1`, `time2`, `time3`, name) VALUES (null, null, null, 't1');
Query OK, 1 row affected (0.02 sec)
greatsql>SELECT  * FROM t1;
+---------------------+-------+---------------------+------+
| time1               | time2 | time3               | name |
+---------------------+-------+---------------------+------+
| 2025-07-08 13:53:58 | NULL  | 2025-07-08 13:53:58 | t1   |
+---------------------+-------+---------------------+------+
1 row in set (0.00 sec)
greatsql>SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `time2` timestamp NULL DEFAULT NULL,
  `time3` timestamp NOT NULL DEFAULT '2025-01-01 00:00:00',
  `name` varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
1 row in set (0.00 sec)
greatsql>SET explicit_defaults_for_timestamp=ON;
Query OK, 0 rows affected (0.00 sec)

greatsql>CREATE TABLE t2( time1 timestamp, time2 timestamp null, time3 timestamp default '2025-01-01 00:00:00', name varchar(100) );
Query OK, 0 rows affected (0.02 sec)

greatsql>INSERT INTO t2  (`time1`, `time2`, `time3`, name) VALUES (null, null, null, 't2');
Query OK, 1 row affected (0.01 sec)

greatsql>SELECT  * FROM t2;
+-------+-------+-------+------+
| time1 | time2 | time3 | name |
+-------+-------+-------+------+
| NULL  | NULL  | NULL  | t2   |
+-------+-------+-------+------+
1 row in set (0.00 sec)

greatsql>SHOW CREATE TABLE t2\G
*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
  `time1` timestamp NULL DEFAULT NULL,
  `time2` timestamp NULL DEFAULT NULL,
  `time3` timestamp NULL DEFAULT '2025-01-01 00:00:00',
  `name` varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
1 row in set (0.00 sec)

可以看到,在 explicit_defaults_for_timestamp 等于OFF的时候,不仅影响写入,还会影响表结构。 time1 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 创建表时该字段自动增加了NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 虽然字段类型是timestamp not nul ,但可以插入 null,数据写入后变为了 CURRENT TIMESTAMP.

解决方法

问题原因

1、explicit_defaults_for_timestamp参数在不同的数据库版本中,默认值不一样。该参数可能导致在低版本的 MySQL 中能执行的语句,在高版本的 MySQL 中不能执行。

潜在影响

MySQL 5.7升级到MySQL 8.0后,某些SQL语句执行可能会报错。

解决方法

1、设置explicit_defaults_for_timestamp=OFF,使该值和MySQL 5.7一致

该参数为全局变量,修改后会影响所有timestamp字段的处理逻辑(如自动添加NOT NULL和默认值),可能引发其他表的兼容性问题,建议仅在全面评估后临时使用,建议优先调整表结构或 SQL 语句。

2、修改表结构

调整字段定义为timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,从根源避免NULL插入冲突;

3、修改SQL语句:将字段插入的null值改为CURRENT_TIMESTAMP。

INSERT INTO `t_interface` 
      (`user_id`, `department_id`, `update_time`, `is_deleted`) VALUES (9, 18, CURRENT_TIMESTAMP, 0);

MySQL 5.7升级到MySQL 8.0.x/GreatSQL 8.0.x的一些关键注意事项

从5.7版本升级到8.0,有以下相关注意事项,请认真核对是否产生冲突或不兼容:

  1. 最好是先升级到5.7.x的最新版本,再升级到8.0.x的最新版本,不要从5.7的小版本直接升级到8.0,尤其是非GA的版本。
  2. 在8.0中,除了 general_log 和 slow_log 之外,其他所有元数据的字典数据都存储在InnoDB引擎表中,不再采用MyISAM引擎表存储。
  3. 在8.0中,默认采用 caching_sha2_password 密码插件,这可能导致部分版本较早的连接驱动、连接客户端无法连接8.0的服务端,也需要同步升级。
  4. 在8.0中,默认采用 utf8mb4 字符集,而5.7版本默认字符集是 utf8(也是 utf8mb3),在做数据迁移时要注意前后对照校验。
  5. 在8.0中,启动时务必先设定好 lower_case_table_names 选项值,且实例启动后不可再更改,在个别不区分大小写的旧系统中迁移时要特别谨慎。
  6. 在8.0中,参数explicit_defaults_for_timestamp默认值为 ON,这可能会影响 timestamp 类型字段的默认行为。
  7. 在8.0中,默认启用event_scheduler,建议在主从复制或MGR中,在所有从节点中都关闭它。
  8. 在8.0中,分组查询GROUP BY的结果不再默认进行排序,需要显式加上ORDER BY才行。
  9. 新增保留字、关键字,详情请见:2.6 保留字、关键字。
  10. 除InnoDB、NDB外,其他引擎不再支持表分区。
  11. SQL Mode不再支持 NO_AUTO_CREATE_USER,也就是不能直接利用 GRANT 创建新用户并授权,需要先 CREATE USER 创建用户,再授权。
  12. 部分参数选项不再支持,例如:innodb_locks_unsafe_for_binlog, old_passwords, query cache相关参数等。
  13. 部分功能、函数不再支持,例如:query cache, PASSWORD(), ENCODE(), DECODE(), ENCRYPT()等。

参考文档

https://greatsql.cn/docs/8.0.32-26/7-migrate-and-upgrade/1-upgrade-to-greatsql8.html

https://dev.mysql.com/doc/refman/5.7/en/server-system-ariables.html#sysvar_explicit_defaults_for_timestamp

https://dev.mysql.com/doc/refman/8.0/en/server-system-ariables.html#sysvar_explicit_defaults_for_timestamp

SpringBoot+Vue+MySQL 民宿在线预定平台 完整可运行版(源码+文档) 本文介绍一套基于SpringBoot+Vue+MySQL的民宿在线预订平台,涵盖用户与管理员双角色全流程功能,实现房源展示、订单管理、支付模拟、数据看板等闭环业务。系统架构清晰,前后端分离,附带完整源码、数据库脚本、万字论文、答辩PPT及部署文档,适合毕设、课程设计或小型民宿二次开发,开箱即用,快速落地。 阅读详情

相关推荐

QuickFix Java 实战(一)协议解析、环境搭建与首个应用

本文是QuickFix Java实战系列的第一篇,详细介绍了FIX协议的核心原理与QuickFix/J引擎的实战应用。内容涵盖FIX协议的标签化通信机制、QuickFix/J库的两种下载方法、协议定义文件解析,并通过一个完整的模拟订单发送示例,指导读者快速搭建首个FIX应用环境,实现消息生成与会话通信。

dog123的博客 495

MySQL 迁移至 GreatSQL 后,timestamp 字段插入报错解析

某业务系统进行国产化适配,将 MySQL的数据迁移到GreatSQL 后,执行 INSERT INTO ,update_time 传参为空时报错,报错信息为:ERROR 1048 (23000): Column 'update_time' cannot be null ,而原来旧的 MySQL 环境中没有这个问题。

ascagawgaf的博客 868

【高等数值分析】Krylov子空间方法

文章目录1. 预备理论1.1 Krylov 子空间1.2 最佳逼近1.2.1 方法一:最佳平方逼近1.2.2 方法二:假设 AAA 对称正定1.2.3 方法三:残差2范数2. 基底正交化2.1 Arnoldi 过程(CGS)2.2 改进 Arnoldi 过程(MGS)2.3 Lanczos过程3. 方程组求解3.1 全正交方法 (FOM)3.2 D-Lanczos方法3.3 广义极小残量法(GMRES)3.4 MINRES 方法 1. 预备理论 现在需要求解一个大规模稀疏方程组 Ax=bAx=bAx=b,可

Glooow的博客 1万+

MySQL 索引深入理解:B+ 树、二级索引、联合索引与查询优化

理解二级索引后,就可以理解回表了。SELECT *MySQL 的执行过程分为三个步骤。覆盖索引(Covering Index)并不是一种独立的索引类型,而是一种查询效果。SQL 查询需要的所有字段,都能够直接从某个索引中获得,不需要再访问聚簇索引获取其他字段。例如:因为user_id已经包含在二级索引中,所以 MySQL 可以直接返回结果。不需要回表。联合索引(Composite Index)是同时使用多个字段建立的索引。它的排序规则是:首先按照user_id排序。当user_id。

m0_64642997的博客 135

OpenClaw插件配置错误修复完全指南

插件文件名是插件目录结构正确package.json配置正确OpenClaw的插件系统还在快速迭代,偶尔会遇到这种配置问题。看错误信息检查配置文件检查实际文件对比差异修复问题大部分问题都能解决。查看官方文档:https://openclaw.ai/docs提Issue:https://github.com/openclaw/openclaw/issues加入Discord社区求助快速修复命令汇总。

Maynor的博客 4096

【华为OD技术面-手撕算法代码真题】- 最长公共前缀

🌟 强烈推荐:华为OD技术面试手撕算法代码真题 🌟大家好!今天我给大家推荐一份备受赞誉的华为OD技术面试手撕算法代码真题。所有题目均为华为od实际面试过程中出现的算法代码真题。

算法大师! 4884

MySQL 单点详解(14)

给定一条 SQL,联合索引的列该怎么排呢?

2401_88601046的博客 345

智能交通实战:基于YOLOv5/8/10的车辆违章行为检测系统(违停/压线/逆行识别)

在开始模型训练前,我们得明确要检测的违章行为,还要准备好对应的数据集,这就像做饭前要确定做什么菜、准备什么食材一样。通过本指南,你已经掌握了从技术选型(YOLOv5/8/10)数据准备模型训练到UI界面开发的全流程,搭建了一套完整的车辆违章行为检测系统。这个系统在实际应用中,能有效识别多种车辆违章行为,检测准确率高、速度快,可用于智能交通管理、停车场管理等多个场景。随着深度学习技术的不断进步,YOLO系列模型在车辆违章检测领域的应用会越来越广泛。

m0_71589036的博客 460

MySQL 的 REPEATABLE READ 到底能不能防幻读——从快照读、当前读到 Next-Key Lock

本文系统讲解 InnoDB 可重复读级别下的幻读问题:从三类读异常切入,剖析快照读依赖 MVCC、当前读依赖 Next-Key Lock 的双防线机制,用双会话实验复现幻读仍会出现的边界场景,并解释各数据库在幻读防护上行为分歧的根源。

大模型全栈工程师 · Thanks_ks 297

实战避坑:基恩士KV8000 PLC与C#上位机链路通讯全流程实现(含ST代码+上位机源码)

本文详细讲解了基恩士KV8000 PLC与C#上位机的TCP链路通讯实现,从PLC端的ST代码编写、通讯配置,到上位机的通讯类封装、界面实现,再到实战避坑和性能优化,提供了完整的可复用方案。该方案已在实际产线项目中验证,支持实时数据采集和控制指令下发,稳定性和可靠性满足工业场景需求。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 1176

20 Embedding 与向量检索:语义为什么能变成距离

Embedding 是 RAG 语义检索的数学基础。本文用工程视角讲清文本如何变成向量,为什么语义相近会表现为距离相近,Top-K 检索如何工作,以及在模型选择、同模型约束、精确匹配和召回评估上的常见坑。

老于的笔记的专栏 6203

Flink SQL 连接器实战:MySQL Source、Flink CDC 与 JDBC Sink 全解析

提供有界流读取,适合批处理和维表场景,简单直接但无法感知变更。MySQL CDC提供无界流读取,通过「全量快照 + binlog 增量」的方式实现实时捕获,是实时数仓的核心入口,但需要 MySQL 侧正确配置 binlog 和权限。JDBC Sink负责结果回写,关键在于区分仅插入流和更新流,更新流必须依赖主键完成 upsert。掌握这三者的差异,本质上就是掌握了 Flink 中「有界与无界」「追加与更新」这两组最基本的语义。

2401_83857914的博客 455

Vue3 - 详细实现微信公众号H5网页内置浏览器中预览下载word文档(doc)、excel表格(xls)、ppt文稿、pdf文档等文件,微信内部直接打开预览和下载到本地教程,安卓苹果手机无差异兼容

vue3,nuxt3,微信公众号,h5,移动端,网页,网站,vue微信内置浏览器下载文件,下载文件,在微信浏览器里面实现下载任意文件,H5需要在微信浏览器中下载excel文件,实现网页在微信内置浏览器中下载文件详细教程,安卓点击下载会提示打开浏览器,后端返回流文件,如何解决无法下载文件,跳转至浏览器下载文件,发送到电脑微信,安卓,苹果,手机系统,微信H5页面,vue3微信公众号H5网站,内置浏览器下载文档,如何在微信浏览器中预览office文件,word文档,excel文档,pdf文档,ppt文档,offi

🏆 前端领域优质创作者 1万+

MySQL 中 DISTINCT 与 GROUP BY 哪个效率更高?

DISTINCT与GROUP BY在纯去重场景下,MySQL 8.0 中执行计划通常一致,效率基本相同。老版本(8.0.13 之前)GROUP BY有隐式排序开销,DISTINCT往往更快。需要聚合或HAVING时,只能用GROUP BY。效率的真正决定因素是索引和执行计划,而不是这两个关键字本身。所以,与其问「哪个更快」,不如问「我的查询有没有走对索引」。

2601_96709915的博客 326

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候 提示IE WebControls 不通过,这个工具可以欺骗u8的检查。 跳过U8环境检测的IE WebControls。提示导入失败后,重新检测通过。

Docker 部署 WordPress+MySQL 高可用架构

点「安装 WordPress」

一直在努力学习的菜鸟 227

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

基于 FastAPI+LangChain+LangGraph+Agent+Vue3+MySQL 的房产数据采集与房价预测分析平台

本文介绍一个完整的「房产数据采集+AI房价预测」全栈项目,涵盖FastAPI异步后端、LangGraph Agent智能问答、爬虫采集、机器学习预测与Vue3前端,实现从数据采集到AI交互的闭环。项目融合多技术栈,具备真实业务场景与生产级设计(如降级策略、流式输出、多模型对比),兼具简历亮点与答辩演示优势,可系统性提升工程能力,并附高频面试题解析,是理想的技术综合实践项目。

深耕开发,专注编程实战。分享源码解析、项目搭建、问题排查笔记,沉淀技术,持续更新。 231

MySQL 8.0 双向主从复制故障修复与重建指南

MySQL 8.0 双向主从复制故障修复 SOP:XtraBackup 重建备用节点,解决 GTID 1236 / 历史日志冲突

「YYL DBA手记」 数据库 · 架构 · 运维 · 实战 yyldba.blog.youkuaiyun.com 298

MySQL 8.0停服了,信创替代的窗口正在关闭

最近跟几个做信创的朋友聊天,发现一个被忽略的问题。MySQL 8.0在今年4月正式停了官方支持,Oracle不再出安全补丁,bug也没人修了。但大量企业的业务系统还跑在上面。这事搁以前不算急,慢慢选就行了。但现在不行了,国资委79号文写得很清楚,2027年底前央国企核心系统得完成国产化替换。MySQL停服跟信创deadline撞在一起,留给MySQL用户做决定的时间不多了。我做过不少数据库迁移项目,MySQL替代这个事,坑比大多数人想的要多。今天聊几个我觉得最容易被忽视的点。

databasedb的博客 333

MySQL:库与表的操作

本文系统讲解MySQL库的操作,涵盖创建、查看、修改、删除数据库及字符集、校验规则的配置与影响。重点说明CREATE DATABASE语法、字符集(如utf8mb4)与校验规则(如utf8_general_ci vs utf8_bin)对大小写敏感性和排序的影响。通过实例演示不同校验规则下查询与排序结果差异。同时介绍SHOW DATABASES、USE、ALTER DATABASE、DROP DATABASE等操作,并强调备份恢复(mysqldump)与连接状态监控(SHOW PROCESSLIST)的重要

2401_87306079的博客 325

MySQL 主从复制进阶(2026):GTID、复制延迟排查与故障切换

load 高到底是 CPU 还是 IO?free 的 available 才是关键。us/sy/wa 决策树 + iostat/sar/iftop 实战,CPU/内存/磁盘/网络四大瓶颈定位方法论。

2502_91473995的博客 182

Linux、Shell、MySQL 测试卷逐题细讲(下篇:MySQL)

本文为Linux、Shell、MySQL测试卷下半段MySQL部分逐题讲解,包含填空、选择与SQL分析三类题型。填空题覆盖COUNT、HAVING、DISTINCT、事务、约束、索引等核心语法;选择题辨析存储过程、索引类型、ACID、存储引擎、用户管理等考点。SQL大题围绕员工、部门、职位、地点四张关联表,考察多表连接、分组聚合、自连接、相关子查询、NULL处理等高频写法,标注LEFT JOIN统计计数、NULL判断、子查询别名等易错坑点,同时梳理试卷OCR识别带来的干扰问题,重点提示SQL实操中的常见失误

dongziwen1的博客 185

MySQL 为什么选择 B+ 树作为索引结构

B 树和 B+ 树都是多路平衡树,但 B+ 树在数据库场景下更有优势,主要体现在以下几个方面。对比对象主要问题B+ 树的优势二叉树 / 红黑树树高过大,I/O 次数多多路平衡,树高仅 3~4 层哈希表不支持范围查询、排序天然有序,支持范围与排序B 树节点存数据,扇出小;查询路径不一致非叶子只存键,扇出大;查询路径稳定B+ 树用更矮的树高减少磁盘 I/O,用有序的叶子链表支撑范围查询,用只存键的非叶子节点换取更大的扇出,是磁盘数据库索引场景下综合表现最优的选择。

2601_96129122的博客 319

任务4-1 了解MySQL的数据类型

本文梳理了MySQL数据类型:数值型涵盖整型与实型,金额首选DECIMAL;字符串型按长度与用途分为CHAR、VARCHAR、TEXT及BLOB;日期型包含DATE、TIME、DATETIME及TIMESTAMP;特殊类型有ENUM、JSON等。掌握类型特性是高效建表的基础。

howard2005的专栏 147

mysql初阶--数据库设计

本文系统阐述数据库设计的核心方法论,从范式理论(1NF、2NF、3NF)出发,揭示数据冗余与操作异常的根源,强调3NF为工程实践的最优平衡点。通过E-R图构建实体关系模型,实现从业务需求到表结构的清晰映射。文章厘清类、实体、表三者对应关系,提出“抽象→建模→落地”的设计流程,帮助开发者建立可复用的数据库设计思维框架,避免“拍脑袋”建表的陷阱。

2601_97033068的博客 704
上一篇: GreatSQL分页查询优化案例实战
下一篇: GreatSQL 优化技巧:最值子查询与窗口函数相互转换
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值