在数据库对应的文件夹下, 表对应的文件(与存储引擎有关)也会被删除
注意: 删除有危险,操作需谨慎(不可逆)
数据操作
新增数据
有两种方案
方案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来验证不同的校对集的效果
