mysql 第一天_Mysql 第一天

在数据库对应的文件夹下, 表对应的文件(与存储引擎有关)也会被删除

注意: 删除有危险,操作需谨慎(不可逆)

数据操作

新增数据

有两种方案

方案1: 给全表字段插入数据, 不需要指定字段列表: 要求数据的值出现的顺序必须与表中设计的字段出现的顺序一致: 凡是非数值数据,都需要使用引号(建议是单引号)包裹

Insert into 表名 values(值列表)[,(值列表)];    -- 可以一次性插入多条记录

方案2: 给部分字段插入数据,需要选定字段列表: 字段列表出现的顺序与字段的顺序无关; 但是值列表的顺序必须与选定的字段的顺序一致.

Insert into 表名 (字段列表) values (值列表)[,(值列表)];

查看数据

Select */字段列表 from 表名 [where条件];

查看所有数据

查看指定字段,指定条件的数据.

更新数据

Update 表名 set 字段 = 值 [where条件];    -- 建议都有where: 要不是更新全部

更新不一定会成功: 如没有真正要更新的数据

删除数据

删除是不可逆的: 谨慎删除

Delete from 表名 [where条件];

中文数据问题

中文数据问题本质是字符集问题.

计算机只识别二进制: 人类更多是识别符号: 需要有个二进制与字符的对应关系(字符集)

客户端向服务器插入中文数据: 没有成功

原因: \xD5\xC5\xD4\xBD代表的是"张越"在当前编码(字符集)下对应的二进制编码转换成的十六进制: 两个汉字 => 四个字节(GBK)

报错: 服务器没有识别对应的四个字节: 服务器认为数据是UTF8, 一个汉字有三个字节: 读取三个字节转换成汉字(失败),剩余的再读三个字节(不够): 最终失败.

所有的数据库服务器认为(表现)的一些特性都是通过服务器端的变量来保存: 系统先读取自己的变量,看看应该怎么表现.

//查看服务器到底识别哪些字符集

Show character set;

基本上: 服务器是万能,什么字符集都支持

//既然服务器识别这么多: 总有一种是服务器默认的跟客户端打交道的字符集

Show variables like 'character_set%';

问题根源: 客户端数据只能是GBK, 而服务器认为是UTF8: 矛盾产生

解决方案: 改变服务器, 默认的接收字符集为GBK;

Set character_set_client = gbk;

插入中文的效果

查看数据效果: 依然是乱码

原因: 数据来源是服务器, 解析数据是客户端(客户端只识别GBK: 只会两个字节一个汉字): 但是事实服务器给的数据却是UTF8,三个字节一个汉字: 乱码

解决方案: 修改服务器给客户端的数据字符集为GBK

Set character_set_results = GBK ;

查看数据效果

Set 变量 = 值; 修改只是会话级别(当前客户端,当次连接有效: 关闭失效)

设置服务器对客户端的字符集的认识: 可以使用快捷方式: set names 字符集

Set names gbk; ====> character_set_client,character_set_results,character_set_connection

Connection连接层: 是字符集转变的中间者,如果统一了效率更高,不统一也没问题.

校对集问题

校对集: 数据比较的方式

校对集有三种格式

_bin: binary,二进制比较, 取出二进制位,一位一位的比较, 区分大小写

_cs: case sensitive,大小写敏感, 区分大小写

_ci: case insensitice,大小写不敏感,不区分大小写

查看数据库所支持的校对集: show collation;

校对集应用: 只有当数据产生比较的时候,校对集才会生效.

对比: 使用utf8 的_bin和_ci来验证不同的校对集的效果