mysql DQL（javaweb第七天）
数据库操作DQL
用于查询数据库表中的数据
查询语句（select）:
select 字段列表
from 表名列表
where 条件列表
group by 分组字段列表
having 分组后条件列表
order by 排序字段列表
limit 分页参数
基本查询：
查询多个字段：
select 字段1，字段2，… from 表名
查询所有字段：（不建议，性能低，建议将全部字段都写出）
select * from 表名
设置别名：
select 字段1 [as 别名1],字段2 [as 别名2] from 表名
//as可以省略
去除重复记录：
select distinct 字段列表 from 表名
select name from tb_user where username='九九';select id, username, name, age, gender from tb_user;select * from tb_user;select name as 姓名 from tb_user;select name 姓名 from tb_user;select name '姓 名' from tb_user;select distinct gender from tb_user;
条件查询
select 字段列表 from 表名 where 条件列表；
比较运算符：
除常见的还有
between 、、、 and 、、、 在某个范围之内（闭区间）
in(、、、） 在in后括号中的一个，多选一
like 占位符 模糊匹配（_匹配单个字符，%匹配多个字符）
is null 是null吗
逻辑运算符：
and或&&
or 或||
not或 ！
分组查询
聚合函数
将一列数据作为一个整体，进行性纵向计算
count 统计数量
| 写法 | 含义说明 |
|---|---|
COUNT(*) | 统计所有行（包括所有字段，不管有没有 NULL） |
COUNT(1) | 实际上也是统计所有行，数据库在执行时会优化成和 COUNT(*) 一样 |
COUNT(列名) | 统计该列中非 NULL 值的行数 |
max 最大值
min 最小值
avg 平均值
sum 求和
select 聚合函数（字段列表） from 表名；
小点：null不参与运算
分组查询：
select 字段列表 from 表名 [where 条件] group by 分组字段名 [having 分组后过滤条件]
where和having有什么区别
1、执行时机不同：
where是分组之前进行过滤，不满足where条件不参与分组
having是在分组之后对结果进行过滤
2、判断条件不同：
where不能对聚合函数进行判断，而having可以
注意事项：
分组之后，查询的字段一般为聚合函数和分组字段，查询其他无意义
执行顺序：
where>聚合函数>having
排序查询
select 字段列表 from 表名 [where 条件列表] [group by 分组字段] order by
字段1 排序方式1，字段2 排序方式2；
ASC:升序（默认）
DESC：降序
分页查询
select 字段列表 from 表名 limit 起始索引，查询记录数；
注意事项：
起始索引从0开始，每页起始索引-（页码-1）*每页数据量
起始索引为0可以省略
流程控制函数：
if(条件，值1，值2）
case 表达式 when 值1 then 结果1 when 值1 then 结果2 else 结果3 end
多表设计
表结构之间关系：
一对多
用于表达“从属”关系（谁属于谁），提高数据复用和一致性
多表问题分析：
部门数据可以直接删除，然而还有部分员工归于该部门下
此时出现了数据的不完整，不一致问题
解决：外键约束
foreign key
外键是一个字段，它必须引用另一个表的主键或唯一约束字段
创建表时指定：
constraint 外键名称 foreign key(外键字段） references 主表（字段名）
建完表时添加：
alter table 表名 add
constraint 外键名称 foreign key(外键字段） references 主表（字段名）
物理外键：
概念：使用foreign key定义外键关联另外一张表
缺点：
影响增、删、改的效率
仅用于单节点数据库，不使用与分布式、集群场景
容易引发数据库死锁，消耗性能
现实中使用：
逻辑外键
概念：在业务逻辑层中，解决外键关联
通过逻辑外键，可以很方便的解决上述问题
一对一
案例：用户与身份证号
用于分离主信息与附属信息（延迟加载、扩展字段）
多对多
用于灵活表达多重匹配关系，符合业务复杂性
案例：老师和学生的关系
实现：
建立第三张表，包含两个表的主键
分类在数据库一般用tinyint表示
可维护性强，可扩展性强
设计步骤
阅读页面原型及需求文档，分析每个模块涉及到的表结构，以及结构之间的关系
根据页面原型及需求文档，分析各个表结构中具体的字段及约束
个人思考
1.在实际项目开发中一般用tinyint 存储分类吗，
为什么不用枚举，或者boolean
在实际开发中，使用 TINYINT 存储分类是最常见、最灵活的做法。虽然数据库支持 BOOLEAN 和 ENUM，但在大型、跨平台、易维护项目中，TINYINT + 后端枚举 是最佳实践，既利于扩展，又便于维护。
2.大家好像都喜欢用自增id表示主键，而不是身份证号码之类的
| 问题项 | 描述 |
|---|---|
| 可变性 | 某些场景下用户可能换手机号、更新身份证等 |
| 冗长 | 像身份证号是字符串，占索引空间大 |
| 多义性 | 手机号可能重复注册多个系统，身份证号可能用于多个用途 |
| 安全性 | 直接暴露身份证/手机号可能带来隐私与安全问题 |
| 不唯一性 | 某些字段（如邮箱）在多个系统中不一定保证全球唯一 |
3.图片存储的是什么
图片存储的是路径
一般varchar(300)