数据库增删改查基本语句

哦，说到数据库，这看起来就像家里的一个仓库。
存放东西应该有规则。
不然物品太多的话，就很难找到了。
例如，2 02 2 年，我们城市的一家公司存储了数千万条数据，包括出行、消费、上网、聊天记录等多种记录。
这些数据包括文本、照片、音乐和其他一切。

过去，数据库就像一个大柜子，由分层数据库和网状数据库组成。
后来演变成了关系型数据库，就像一个格子柜子，一目了然。
2 0世纪8 0年代，几乎所有数据库都支持关系型数据库，非关系型数据库也纷纷效仿，创建了支持关系型数据库的接口。

要更改数据，必须使用update语句，后面跟表名，然后使用set语句明确指出要更新哪些字段以及哪些字段需要更改。
在某些情况下，您可能需要使用where语句来限制要更新哪些行等。
这些关系数据库非常擅长管理和存储此类数据。

然而，随着云计算和大数据的出现，关系数据库已经显得有些力不从心了。
这是因为越来越多的半关系型和非关系型数据也需要数据库管理。
这就像我的城市。
2 02 2 年数据量将快速增长，现有数据库可能不够用。

数据库的增删改查语句

那天在咖啡店里坐在我旁边的那个人皱着眉头看着他的笔记本电脑，嘟囔道：“我又删除了错误的数据。
”他是一名新调来的数据分析师，在电子商务后端调试 SQL 脚本。
我看了一下他的屏幕，上面有我注释掉的删除语句，在空白状态下他想测试一下语句格式，但可能忘了添加过滤条件。

这让我想起去年在客户现场的经历。
他们有一个旧系统，管理员过去常常使用 TRUNCATE 来清除表，因为它更快。
直到我发现所有备份恢复表的自增ID都是从1 0000开始的，数据整合就彻底乱了。
客户端很关心，需要手动重置表结构。

实际上，数据库就像一个经过分类和组织的壁橱。
如果您正在寻找一件蓝色衬衫，您不能直接扔掉衣柜里的所有衣服。
定义“这是蓝色”的地方是“这是蓝色”；删除是“删除这个蓝色”，更新是“用新环替换这个蓝色”。
但有时像 TRUNCATE 这样的操作会烧毁整个机柜这就像重建。
所以你必须非常小心。

等等，还有一个。
上次我使用MySQL内置的EXPLAIN来分析查询。
我发现一个带有嵌套 JOIN 的 SQL 和执行计划中的一个表扫描了 3 亿行。
切换到子查询嵌套后，相同数据量的扫描数据量大幅下降至2 000行。
这就是为什么在写SQL的时候，不仅要考虑如何写得流畅，还要考虑如何让数据库运行得更快。

我突然想到，现在很多BI工具会自动生成SQL，有时会生成特别复杂的子查询或隐式JOIN。
客户使用 Tableau 连接到 Oracle 数据库。
报告运行了 5 分钟，日志已满“全表扫描”。
最后发现某个计算字段在WHERE条件下进行了隐式类型转换。
如果没有监控的话。
这将是“数据库挂起”的直接情况。

用SQL语句随便写一条数据库增删改查语句

说实话，刚接触数据库的时候，那些SQL语句让我很头疼。
但后来习惯了，发现用起来还是蛮简单的。
我们以插入数据为例。
最让我印象深刻的是当我向客户端系统添加用户时。
使用insert into比使用Excel手动导入和填写要快得多。

有趣的是，我还踩到了省略表名的陷阱。
我曾经写过一个批量导入脚本，忘记添加表名。
结果，所有的列都被插入了，数据变得一团糟。
后来我了解到，如果省略表名，MySQL会按照默认顺序插入。
如果表结构发生变化就到此为止。
所以现在在编写脚本之前我总是写表名或用列名来明确说明。

说到删除，我花了很长时间才明白delete和truncate的用法。
我曾经想删除一个测试表，但是我使用了delete from并添加了Where条件。
仅删除了几行。
我对自己说，“不是这样的。
”最后我发现我忘记写where后面的条件了，后来被师傅骂了才想起来，删除是行级操作，没有任何条件就删除整个表（虽然性能很差），truncate就更无情了，秒级就能抹掉数据。
但是如果有外键关系，比如依赖用户ID的用户表，截断就不行了，必须删除
我经常使用更新操作，比如要更改工资，关键是要知道如何编写定义后的多个列。
大约在这个时候，一个实习生写了一个员工更新，设置工资= 5 ,000，部门=“IT”，但忘记了添加位置，并且整个公司员工都转到了IT部门 - 即使这只是一个笑话，但在实际操作中，您也不应该掉以轻心。
使用select，但是在写复杂查询的时候，Where子句的优先级和order by总是让我很头疼，有一次我想按年龄排序，结果还是按年龄顺序写的。
一开始很迷茫，后来熟练了就成了肌肉记忆了，但有时候还是会很困惑，比如忘记加引号或者写and而不是or，结果查询结果都是错的，所以现在在写SQL之前，我总是默念三遍“检查条件、检查引号、检查逻辑”来提醒自己。