请关注我的微信公众号
个人微信公众号
技术交流群 (仅作技术交流)：642646237
请关注我的头条号：
表连接(join)概念
一个表的行根据指定的条件跟另一个表的行连接起来形成新的行的过程。
表连接的分类——根据查询返回的结果
1.内连接（inner join）
2.外连接（outer join）
3.交叉连接（cross join）
表连接的分类——根据连接条件
- 相等连接（使用等号操作符）
- 不等连接（不使用等号操作符）
标准的连接语法
多表连接需要连接条件
多表查询在每张表的数据量比较大的时候，会导致很可怕的事情。
曾经在线上发生过这样的事情，直接导致系统的卡死。
优化器评估返回的数据量为3505T条记录，计划返回量127P字节，总成本9890G，返回时间999：59：59。
多表关联缺乏连接条件，导致笛卡儿积。
笛卡儿连接是指在两表连接没有任何连接条件的情况。应尽量避免笛卡儿积。
（2）模拟场景相关代码如下：
对于普通的采用数值类型的字段，范围查询就是正常的索引范围扫描，执行效率很高。
对于文本类型字段的表，范围查询就是对应的全表扫描，效率较低是显而易见的。
（3）分析结论·字符类型在索引中是“乱序”的，这是因为字符类型的排序方式与我们的预期不同。从“select*from t2 where id>='3199990'”执行返回755565条记录可见，不是直观上的10条记录。这也是当初在做表设计时，开发人员没有注意的问题。·字符类型还导致了聚簇因子很大，原因是插入顺序与排序顺序不同。详细点说，就是按照数字类型插入（1..3200000），按字符类型（'1'...'32000000'）t排序。
在对字符类型使用大于运算符时，会导致优化器认为需要扫描索引大部分数据且聚簇因子很大，最终导致弃用索引扫描而改用全表扫描方式。
（4）解决方法具体的解决方法如下：
将SQL语句由开放区间扫描（>=），修改为封闭区间（between xxx and max_value）。使得数据在索引局部顺序是“对的”。如果采用这种方式仍然走索引扫描，还可以进一步细化分段或者采用“逐条提取+批绑定”的方法。2.给我们的启示这是一个典型的由不好的数据类型带来的执行计划异常的例子。它给我们带来如下启示：·糟糕的数据结构设计往往是致命的，后期的优化只是补救措施。如果从源头上加以杜绝，这才是优化的根本。·在设计初期能引入数据库审核，可以起到很好的作用。
网友评论