MYSQL数据库语法补充2

一,数据库设计范式(原则)

数据库设计三大范式:

第一范式: 保证列的原子性(列不可再分)  反例:联系方式(手机,邮箱,qq)  正例: 手机号,qq,邮箱.

第二范式: 要有主键,其他列依赖于主键列,因为主键是唯一的,依赖了主键,这行数据就是唯一的.

第三范式: 多表关联时,在一个表中,只关联另一个表的主键即可,不需要关联另一个表的非主键列.

二,多表设计:

在项目开发的过程中需要用到很多的数据,把不同的数据存储在不同的表中(分类存储),但数据(表)之间又存在关系

外键:使用外键引用另一个数据表的某条数据,外键列类型与主键列类型保持一致

数据表之间的关联/引用关系是依靠具体的主键(primary key)和外键建立起来的.

举例1:

学生信息与专业信息表

-- 设计 专业信息表,  学生与专业信息表有关系
create table major(
    id int primary key auto_increment,
    name varchar(10),
    major_desc varchar(50)   
)

下列为在初始定义表时没有添加外键

后补加外键

-- 修改表 添加列   najorid 称为外键列, 外键列只能与另一个表的主键关联
alter table student add column majorid int
-- 修改表 删除列
alter table student drop column majorid

-- 修改表,为外键列添加外键约束,保证数据的完整性
                --  添加约束               约束名字                    外键列       与 哪个表的主键列关联          
alter table student add constraint fk_student_major_on_majorid foreign key(majorid) references major(id)
-- 删除外键约束
alter table student drop foreign key fk_student_major_on_majorid

也可以直接创建带有外键约束的学生表

create table student(
 id int primary key not null auto_increment,-- 设置主键
 num int,-- 学号
 name varchar(10),-- 学生姓名
 majorid int,-- 专业外键
 constraint fk_student_major_on_majorid foreign key(majorid) references major(id) -- 添加外键约束
)

约束名规则:fk_foreigntable_primarytable_on_foreigncolumn 其中foreign指含有外键的表,primarytable指外键需要关联的主键所在的表,foreigncolumn指外键列
 

举例2:

学生选课案例 多对多关系

create table course(
   id int primary key auto_increment,
   name varchar(20)
)
-- 创建学生选课表(学生和课程的关系表)
create table student_course(
  studentid int,
  courseid int,
  constraint fk_student_course_student_on_studentid foreign key(studentid) references student(id),
  constraint fk_student_course_course_on_corseid foreign key(courseid) references course(id)
)

三,关联查询

含义:又称多表查询,当查询的字段来自于多个表时,就会用到连接查询

笛卡尔乘积现象:表1有m行,表2有n行,结果=m*n
        发生原因:没有有效的连接条件
        如何避免:添加有效的连接条件

按照功能分类:

内连接

外连接

        左外连接

        右外连接

子连接

  -- 笛卡尔乘积现象 由于两张表关联没有关联条件,用第一张中的每行与关联表中的每行进行关联
  select s.num,s.name,s.gender,s.majorid,m.id from student s,major m
  -- 解决办法,添加关联条件
  -- 内连接  只把满足条件的数据筛选出来
  -- 写法1(推荐写法)
  select s.num,s.name,s.gender,m.name from student s inner join major m on s.majorid = m.id
  
  -- 写法2:
  select s.num,s.name,s.gender,m.name from student s,major m where s.majorid  = m.id
  
  /*
     写sql方法分析
     1.根据题目分析出数据来源自哪些表
     2.关联条件 哪两个列作为条件关联
     3.确定查询结果
  */
  -- 
  select s.num,s.name,s.gender,m.name from student s inner join major m on  s.majorid = m.id
  
  -- 外连接--左外连接  不管条件是否成立,都会把左边表中的数据全部查询出来,右边表只会查询出满足条件的数据
  select s.num,s.name,s.gender,m.name from student s left join major m on s.majorid = m.id
  
 -- 外连接--右外连接,不管条件是否成立,都会把右边表中的数据全部查询出来,左边表只会查询出满足条件的数据
  select s.num,s.name,s.gender,m.name from student s right join major m on s.majorid = m.id
  
  

四,子查询

含义:出现在其他语句中的select语句,称为子查询或内查询.
一般子查询多用于查询语句(查询语句中再出现一个查询)
分类:
按子查询的位置:
    select后面:支持表量子查询
    from后面:支持表子查询
    where后面:支持标量子查询,列子查询
按功能,结果集的行数不同:
    标量子查询(结果集只有一行一列)
    列子查询(结果集只有一行多列)
    表子查询(结果集一般为多行多列)

-- 标量子查询(查询结果只有一行一列)  适用于select和where后面
select s.num,s.name,(select m.name from major m where m.id = s.majorid) from  student s

select * from student where height = (select max(height) from student) 

-- 列查询(结果集只有一列多行)
select * from student where height in(select height from student where height>1.60 and height<1.99)

-- 表子查询  把一个查询的结果当做一张表,为另一个查询提供数据
-- 一次查询处理不完, 写一个查询进行处理
 select * from (select name,count(*)c from student  group by name )t where t.c>1
 

<think>嗯,用户需要将DB2数据库迁移到MySQL,这确实是个技术活。从引用内容来看,用户已经收集了一些碎片信息:IBM MTK工具、Navicat转换、timestamp类型兼容问题。不过这些引用比较零散,需要系统化整理。 用户提到"市面上各种数据库语法不同",看来深有体会啊。ta的用词"真是醉了""最难用的"透露出对数据库差异的烦躁情绪,但最后那句"客户是上帝"又显得很务实。这种迁移需求通常是甲方驱动的,用户可能是个被迫接活的开发。 技术上要重点解决三个层面: 首先结构迁移,DB2的TIMESTAMP默认值在MySQL 5.7会报错,这是版本差异导致的经典问题。考虑提醒用户检查所有时间字段,可能需要修改sql_mode。另外DB2特有的XML类型在MySQL没有直接对应项,得建议用JSON或TEXT替代。[^3] 其次数据迁移工具链,IBM MTK确实专业但配置复杂,navicat虽然简单但大表可能超时。如果用户数据量在百万级以内,用CSV中转反而稳定。[^1][^2] 最后应用适配,DB2的递归查询WITH RECURSIVE在MySQL 8.0才有,如果用户用的MySQL 5.7就得重写逻辑。MERGE语句也要改成ON DUPLICATE KEY UPDATE,这些语法差异最容易引发生产事故。 用户没提具体数据规模和MySQL版本,考虑在回复中补充询问。安全起见准备加入回滚方案,毕竟数据库迁移失败需要快速复原。ta引用的资料里都忽略了测试环节,考虑强调迁移后必须做数据校验。 对了,用户上次提问时系统要求生成相关问题,这次准备延伸工具链选择(比如是否需要部署DataStage)、性能调优(编码转换可能导致的性能下降)、增量迁移方案(如果要求不停机)等方向。[^1] </think>以下是将DB2数据库迁移到MySQL数据库的系统性方法及注意事项,结合技术文档和迁移经验整理而成: --- ### **一、迁移流程** #### 1. **结构迁移(Schema Conversion)** - **工具推荐**: - **IBM MTK (Migration Toolkit)**:IBM官方工具,支持全量迁移(结构+数据),自动转换数据类型(如DB2的`TIMESTAMP`转MySQL的`DATETIME`)[^1]。 - **Navicat Premium**:图形化操作,支持跨数据库结构同步(需手动调整语法差异)[^2]。 - **手动调整重点**: - **数据类型**:DB2的`XML`类型需转为MySQL的`JSON`或`TEXT`;`DECFLOAT`转`DECIMAL`。 - **默认值**:DB2的`GENERATED ALWAYS AS IDENTITY`需改为MySQL的`AUTO_INCREMENT`。 - **注释语法**:DB2用`COMMENT ON TABLE`,MySQL用`/*...*/`或`ALTER TABLE`[^3]。 #### 2. **数据迁移(Data Transfer)** - **批量导出导入**: ```bash # DB2导出CSV db2 "EXPORT TO data.csv OF DEL SELECT * FROM table" # MySQL导入(需匹配字符集) mysql -u root -p --default-character-set=utf8mb4 db_name \ -e "LOAD DATA LOCAL INFILE 'data.csv' INTO TABLE table FIELDS TERMINATED BY ','" ``` - **工具自动化**: - **AWS DMS**:支持增量迁移,处理大表分页。 - **Pentaho Kettle**:开源ETL工具,可编写转换脚本处理特殊字符。 #### 3. **代码适配(SQL Rewriting)** - **函数/语法替换**: | DB2 语法 | MySQL 替代方案 | |-------------------|-----------------------| | `NVL()` | `IFNULL()` | | `CONCAT('a','b')` | `CONCAT_WS('','a','b')`| | `FETCH FIRST n ROWS` | `LIMIT n` | - **存储过程**:需重写,DB2的`CURSOR`循环逻辑改为MySQL的`WHILE`循环。 --- ### **二、关键注意事项** 1. **字符集与编码** DB2默认`UTF-8`,MySQL需显式指定`utf8mb4`(支持Emoji): ```sql ALTER DATABASE target_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ``` 2. **时间戳兼容性** DB2允许`0000-00-00 00:00:00`,MySQL 5.7+默认禁止: ```sql -- 关闭严格模式(临时方案) SET GLOBAL sql_mode = 'NO_ZERO_IN_DATE,NO_ZERO_DATE'; ``` 3. **事务与锁机制** - DB2的`RR(可重复读)`隔离级别更严格,MySQL默认`REPEATABLE READ`可能需调整。 - 大表迁移时分批次提交(每1万条`COMMIT`),避免锁超时。 4. **索引优化** DB2的`CLUSTER INDEX`需改为MySQL的`PRIMARY KEY`聚簇索引,非唯一索引显式声明`USING BTREE`。 --- ### **三、验证与回滚方案** 1. **数据一致性校验**: - 使用`CHECKSUM TABLE`对比源/目标表哈希值。 - 抽样执行统计:`SELECT COUNT(*), MAX(id) FROM table`。 2. **回滚准备**: - 迁移前完整备份DB2数据(`db2 backup db dbname`)。 - 记录MySQL的`binlog`位置,异常时通过`mysqlbinlog`恢复。 --- ### **四、迁移工具对比** | 工具 | 适用场景 | 缺点 | |------------------|------------------|--------------------| | IBM MTK | 全自动小型库迁移 | 复杂类型转换易失败 | | Navicat | 可视化快速迁移 | 大表超时中断 | | Shell脚本+CSV | 增量数据同步 | 需手动处理编码 | | AWS DMS | 云环境持续同步 | 配置复杂成本高 | > **推荐策略**:结构迁移用IBM MTK + 数据迁移用CSV分批次导入(安全可控)[^1][^2]。 --- ### **相关问题** 1. DB2的`XML`数据类型迁移到MySQL时如何优化存储结构? 2. 迁移过程中如何最小化业务停机时间? 3. MySQL 8.0有哪些特性可简化DB2迁移?(如CTE递归查询替代DB2 `CONNECT BY`) > 引用说明:IBM MTK工具支持跨数据库语法转换[^1],Navicat适用于图形化迁移[^2],时间戳问题需调整SQL模式[^3]。 迁移后建议用`pt-table-checksum`做最终校验,确保零差异。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值