left join、right join、inner join、full join

说白了，四种SQL连接查询的区别在于返回数据的完整性，与查询过程无关。
内连接是最简单的。
这只会为您提供两个表中匹配的数据 - 例如，Person 和 Order 表中的 Id_P 完全相同。
去年我们跑那个电商项目，用INNER JOIN过滤了3 000个主单，效率很高。
左连接是不同的。
即使右表（订单）不匹配，这也应该为您提供左表（如人员）中的所有数据。
去年CRM系统使用LEFT JOIN的时候，我一开始以为没有数据。
后来我意识到有些不对劲。
事实证明，所有那些在左表中没有订单的顾客都丢失了——许多人没有注意到这一点。
右连接与左连接相反。
即使左表（人员）不匹配，右表（订单）中的所有数据也必须存在。
它很少被使用，但非常有趣。
例如，在获取所有订单信息和填写客户姓名时使用。
FULL JOIN是最全面的，左右表不匹配就得试一试。
当我们去年创建报告时，我们希望看到所有客户和所有订单的交集。
结果FULL JOIN的数据量暴增，直接烧毁了服务器CPU——说实话，挺尴尬的。

等一下，还有一件事。
这些连接不取决于表的大小，而是取决于数据匹配。
例如，如果人员表有 1 ,000 个条目，订单表有 5 00 个条目，那么 LEFT JOIN 可以返回 1 ,000 个条目，而 INNER JOIN 只能返回 2 00 个条目。
我认为尝试动态选择连接方法是合理的，但您应该首先了解您的数据状态。

SQL准确查一串数字的语法

记得上次帮小李编辑报表时，他写的SQL很长。
他在表中查找字段不包含字母或数字的条目。
他使用的不是“%[0-9 a-zA-Z]%”。
当时我就觉得这种写法很特别。
后来查了手册，确实LIKE后面加%表示任意多个字符，里面加[]表示任意多个字符。
那么外面加个^就代表里面不包括在内？ [^0-9 a-zA-Z]可以这样写吗？但小李的写法虽然行得通，却显得有些混乱。
等等，好像他表里的字段都是中文写的。
他这样写，是不是把所有的汉字都排除掉了？这需要检查。
我打开数据库，找到了一个测试环境，比如北师大的旧服务器。
我记得是去年1 2 月安装的。
我正在尝试查找一个随机帖子，例如 ID 1 001 ，其字段值为“Hello”。
我运行了小李的SQL查询，结果确实是“Hello”。
似乎所有英文字符和数字都被排除了。
如果该字段仅包含字母，例如“Test”，则不会找到此条目？我添加了一个 ID 为 1 002 且值为“Test”的测试。
我再次运行SQL，结果为空。
这种记录方式看来还是靠谱的。
但我突然想到，如果场地是空的，或者里面只有空格，会发生什么？例如，ID为1 003 ，值为“”。
如果再次运行SQL，结果仍然为空。
如果值为“”怎么办？我会尝试执行，但结果仍然是空的。
看来空格也被排除了。
有点复杂。
如果你的业务需要计算空格，那么这种写法就行不通了。
我们需要改变这一点。
例如，将其更改为 LIKE '%[^0-9 a-zA-Z]%' 并查看效果。
我将更改它并再次运行它。
好吧，ID 1 003 - 这次成功了。
看来只要不是英文字母和数字，都可以找到。
这实际上解决了空间问题。
但这种记录方式似乎比较复杂。
不幸的是，您实际上可以只使用 NOT LIKE '%[0-9 a-zA-Z]%'，但您必须确保并非所有字段都是中文。
这个问题必须得到小李的确认。
他的报告现在运行缓慢吗？我查了日志，他上周五提过一次，说有点卡，但没说严重。
你必须提醒他注意这一点。

mysql版本号怎么查询

上周，我想查看公司服务器上MySQL的版本号，所以尝试了四种方法：
方法一：直接将SQL导入MySQL客户端，SELECT VERSION();立即看到版本号 8 .0.3 3
方法二：我也是进入了SELECT@@版本；在 MySQL 客户端中。
结果与方法1 相同，均为8 .0.3 3
方法3 ：我在终端尝试了mysql -V，发现输出是mysql Ver 8 .0.3 3 for Linux on x8 6 _6 4 (MySQL Community Server (GPL))。
这个命令行方法也有效。

方法四：我还用Python写了一个小脚本，连接MySQL数据库，执行SELECT VERSION();，然后打印出来，也是8 .0.3 3
总而言之，选择命令行或 SQL 语句进行快速查询，并使用客户端库进行编程集成。
但请注意，命令行工具路径必须添加到环境变量中，并且某些方法可能需要管理员权限。
这取决于您，使用您方便的任何方式。