SQL优化

本文将帮助您深入了解索引在数据库表中的作用，以及使用\"explain analyze\"命令来分析查询计划的方法。

PostgreSQL数据库中SQL查询的优化方法和技巧，以提升查询性能。其中包括使用UNION语句和去重操作等技术来改进存在OR条件的查询语句。

🌈键盘敲烂，年薪30万🌈 目录 一、索引优化 回顾： 📕索引分类： 📕索引失效： 📕设计原则： 📕SQL性能分析 二、SQL优化 语句优化 📕 insert语句： 📕 主键优化： 📕 order by优化： 📕 group by优化： 📕 limit 优化 📕 count 优化 📕 update 优化  📕索引分类： 一般分类：主

批量插入 手动提交事务 主键顺序插入 如果一次性需要插入大批量数据，使用insert语句插入性能较低，此时可以使用MySQL数据库提供的load指令进行插入。操作如下: 主键顺序插入性能高于乱序插入 在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称

1 概述 在之前的测试中，我们发现，如果数据量很大，在执行count操作时，是非常耗时的。 MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高； 但是如果是带条件的count，MyISAM也慢。 InnoDB 引擎就麻烦了，它执行 count(*) 的时候，

MySQL的排序，有两种方式： Using filesort : 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。 Using index : 通过有序索引顺序扫描直接返回有序数据，这种情况即为 using

  目录 1、批量插入数据 1.1 linux环境下 1.1.1 开启文件读取 1.1.2 load数据 1.2 windows环境下 2、order by优化 2.1 最左前缀 3、group by 3.1 最左前缀 4、count优化 5、or条件优化   在上一期说到索引的使用，这期来聊一下SQL优化，也是平常写SQL的时候常用到的。 在前几期也有聊到过批量插

  我们这里配置一Windows上的MySql做主机，Linux上的MySql做从机，搭建一主一从 测试以下是否能够拼通：从Linux上：167，连接Windows的165 从Windows的165 连接Linux上：167，看是否拼通   修改配置文件：首先Windows：my.ni 主机配置文件修改： 从机配置文件修改：   注释掉server-id ，打开

   加读锁和写锁 查看是否上锁：In_use：变成了1    读写锁对我们数据产生哪些影响： 读锁：是共享锁，其他线程可以查看： 加了读锁：session1不能修改自己，也不可以读其他表 但是session2窗口可以读其他表  session2：此时对加锁的表进行更改操作，它会进入阻塞状态   

简单的查询类型是：simple   外层 primary，括号里subquery  用到了临时表：derived   trpe反映的结果与我们sql是否优化过，是否是最佳状态息息相关 最简单的查询啥都没有改type就是all：表明的的检索是全表扫描   const：通过id查询，有索引查询很快  t1查询完之后作为一张临时表

对sql调优的分析： 排序优化：  数据库的连接方式，里面的数据尽量这样连接，尽量选择第一个方式，因为两个表的连接一共建立5次连接，第二个建立1000次连接，从小表驱动大表方式来说选择第一种 B相当于部门， A是员工，通过部门id在部门表里面，部门是少量的，员工是

      上面的功能已经实现，但是分析功能， 使用explain分析这条sql： 发现type为All Extra：有Using filesort （文件内排序） 这两个是影响性能的    查看下这张表：只有一个主键索引  为这几个字段建立一个符合索引：   建立完索引后，在使用explain进行分析一下：type变成了r

  查看一下有没有建立索引： 用到索引中的一个：type中的ref决定访问性能  用到索引中的两个：通过key_len的长度可以看出来，比第一个大一点。或者通过ref：中用到了两个常量const 用到了三个索引：key_len比第二个又大了一点，用到了三个常量const 一下的结果都能查出，但是

新的一个优化的方式show Profile   运行一些查询sql： 查看一下我们执行过的sql   显示sql查询声明周期完整的过程：  当执行过程出现了下面这4个中的时，就会有问题导致效率慢  8这个sql创建了临时表导致sql变慢 Show Profile：记录了我们后台要开启的一些sql，全局查询日志呢，

type下的ref是非唯一性索引扫描具体的一个值 ref属性 例如：ti表先加载，const是常量  t1.other_column是个t1表常量 test.t1.ID：test库t1表的ID字段        t1表引用了shared库的t2表的col1字段，t1.col2=‘’ac‘’是一个常量  t2表没有索引只有id主键，col1，col2没有建立索引      rows越少