SQL菜鸟学习札记（二）

五月份一直在写SQL，之后写了一个期末大作业的项目，现在才有时间把之前遇到的各种奇怪的问题整理出来。下一部分札记应该是大作业中使用到的SQL的整理。

 

一.UPDATE SET语句后面可以并列赋值。

之前一直用的两段SQL脚本来分别赋值，效率很低，整合到一个SET语句之后效率翻倍了。（这个很基础）

1 use msi2017;
2 set sql_safe_updates = 0;
3 update finallistnum_result inner join finallistname_num 
4 on finallistnum_result.raceNum = finallistname_num.raceNum 
5 set finallistnum_result.TeamA = finallistname_num.TeamA , 
6 finallistnum_result.TeamB = finallistname_num.TeamB; 

 

二.UPDATE语句的并列问题

可以理解为，每个UPDATE语句都相互独立，可以在同一SQL脚本中并列，但不可以共用同一个UPDATE语句头。

use msi2017;
update finallistnum_result set finallistnum_result.raceResult_TeamB_G1 = 'WIN' 
where finallistnum_result.raceResult_TeamA_G1 = 'LOSE';
update finallistnum_result set finallistnum_result.raceResult_TeamB_G1 = 'LOSE' 
where finallistnum_result.raceResult_TeamA_G1 = 'WIN';

 

三.又是之前遇到的safe update mode（安全更新模式）的设置问题，错误代码1175。

不用慌，下面的SQL脚本已经写出了解决方法（之前也有数次用到这个），就是在脚本头部添加一句"SET sql_safe_updates = 0;"，这样就不会报错了。

在自己写SQL脚本的时候这句话会很常用，因为在运行SQL脚本的时候相当于外部接入数据库修改数据，所以会有一个安全性判断的问题，一般这个判断是不给通过的，所以会报错。设置为0就可以跳过这个判断过程，脚本就可以顺利运行。

因为这个有一部分是笔者之前手动录入的数据，所以其实这段脚本对内容没有修改，但可以成功运行。

插入剩下的数据后，运行脚本，右边一列的数据就成功插入了。

SET sql_safe_updates = 0;
SELECT * FROM msi2017.finallistnum_result;
UPDATE finallistnum_result SET raceResult_TeamB_G1 = 'WIN' where raceResult_TeamA_G1 = 'LOSE';

 

四.内联UPDATE的并列和UPDATE的并列是类似的。UPDATE之间用分号隔开。

五.NOT NULL的不必要性和NULL的重要作用。

在建表的时候，尽量将非主键的其他键值默认值设置为NULL，否则在赋值的时候就会遇到这样的问题。

错误代码：1364。某个键没有默认值。如果建表的时候设置为NULL，就不会提示这个了。能少点麻烦就少点麻烦，后面需要改属性再改......没有默认值会很影响插入数据的效率。

所有的麻烦都是刚开始的自以为是......这样的话，插值就只能将前三列同时插入，要么就一列都插不进去，这个NOT NULL真的不能乱选啊......

这里说一点题外话：虽然SQL对关键字的大小写不敏感，但在大多数情况下，还是建议大家用大写，语句更统一，看着也更舒服不是。

 

六.复制性建表的SQL脚本。

CREATE TABLE table1 SELECT * FROM table2;

建立table1，并且将table2的整个表格照搬到table1。简言之，table1与table2在这个时间点唯一不同的只有表名，其他的东西都是完全相同的，包括表中截止这个时间点已经插入的数据，以及表格中每个键的属性，注释。

这里有个比较偏的东西，就是在这样复制表格的时候，表注释是不会复制的。这里说的表注释是指对整个表格的注释，而不是对每个键的单独注释。

这个表注释不复制，就得自己一个个写进去，如果表格比较多的话，还是挺麻烦的，这也算是MySQL少有的几个用户痛点。

use msi2017;
CREATE TABLE finallistnum_assistnum_top
select * from finallistnum_killnum_top;

 

七.枚举ENUM的使用细节。

这个格式真是刚开始把笔者坑惨了。要求很严格，必须是ENUM('value1','value2','value3')。必须是英文符号，单引号！

这里顺便说一下，SQL脚本在添加联合主键的时候，必须移除之前的主键，再添加联合主键。也就是说，不是从1+1=2，而是从1-1=0，到0+2=2的过程。

ALTER TABLE 'exhotel'.'room'
CHANGE COLUMN 'hotelNo''hotelNo' INT(6) NOT NULL,
DROP PRIMARY KEY,
ADD PRIMARY KEY('roomNo','hotelNo');

 

八.RENAME在Workbench后台脚本是无法被识别的。（好像是这样？）

查了很多资料，在Workbench后台写SQL脚本改表名好像是运行不了的。有图有真相。

话说回来，其实在Workbench中不需要在后台写SQL脚本改表名，直接切换到表属性页面就可以直接改了。不过在需要写大量SQL脚本来修改许多属性或者数据的时候，这样子的效率好像相对就低了点。

 

九.UNIQUE与主键的关联。

没有UNIQUE的表格是无法修改的，只能读取(Read Only)，这个和主键联系起来可以理解。输入一行数据，如果没有主键，那怎么区分这行数据和其他数据的不同点？这也许在我们看来是可以区分的，但SQL是不能区分的，所以它强制每个表格都必须有UNIQUE INDEX（唯一索引），通常唯一索引就以主键为基础来建立。

插入唯一索引后，下方的Apply和Revert按钮就出现了，现在就可以对表格数据进行修改了。

 

十.清除表数据TRUNCATE的使用。

TRUNCATE是清除表中数据的关键字，它只清除数据，不移除表结构。

use msi2017;
TRUNCATE TABLE regseasonnum_createdamage_adc;

 

十一.接着说缺少UNIQUE INDEX（唯一索引）的表格操作。

之前说到只读，这种只读的程度是什么呢？是可以对整个表读取，也可以读取其中的部分键值。

设置UNIQUE INDEX之后，是不是就可以随意修改了呢？当然不是，在修改的时候，必须选择出主键列，否则SQL是不给你修改数据的权利的。

在我们的理解中，可能A（主键）的部分数据具有独特性，可以表征这就是A的数据，但SQL是无法识别这种附庸关系的。所以还是老老实实把主键带上......

在SELECT语句中加入UNIQUE INDEX（唯一索引）列之后，表格就可以修改了。

 

十二.唯一索引的添加位置。

笔者观察了一下，唯一索引的添加总是在SQL脚本的末尾，以 ADD UNIQUE INDEX 'indexname'('indexfor' ASC);为常用格式。这里indexname指这个索引的名字，indexfor指这个索引是为哪个键（列）建立的。

 

终于整理完了，下一部分应该就是大作业的SQL整理了。本SQL菜鸟还有很长的路要走啊......