您当前的位置:首页 > 电脑百科 > 数据库 > 百科

sql性能优化以及性能测试

时间:2023-05-19 15:04:11  来源:今日头条  作者:程序员梓羽同学

笛卡尔连接

没有携带on的条件字句,此条slq查询的结构集等价于,a表包含的条数*b表包含的乘积

select * from table a cross join table b;

拥有携带on字句的sql,等价于inner join

select * from table a cross join table b on a.id=b.id;

 

分页limit的sql优化的几种方法

表包含的数据较少,作为驱动表(小表驱动大表,一般MySQL的优化器会做出相应的优化的,但是为了防止一些抽风现象可以用STRAIGHT_JOIN,作用会强制使用左边的表作为驱动表)

select * from table c straight_join table d on c.id=d.id;

方案①:覆盖索引

select 主键字段或者创建过索引的字段 from table limit 300000,10

方案②:索引覆盖+inner (业界常用的优化方案)

select * from table a
inner join (
select 创建索引的字段 from table  limit 30000,10) b
on b.创建索引的字段=a.创建索引的字段 (也可以更换为 using (创建索引的字段))

方案③:索引覆盖+子查询 先获取分页起始的最小值,然后再获取后10条 (业界常用的优化方案)

select * from table
where 主键字段或者创建过索引的字段
>=
(select 主键字段或者创建过索引的字段 from table 300000,1)
limit 10;

方案④:范围查询+limit语句 获取上一页的主键最大值,然后进行获取后面的数据

上一页的最大主键值为100

     select * from table
     where id > 100
     limit 10;

方案⑤:需要获取起始主键值和结束主键值

select * from table where id between 起始主键值 and 结束主键值;

方案⑥:禁止传入过大的页码 (百度就是采用这种方式)

count 优化方案总结

例1:

    /**
    * 1:如果不包含非主键的索引,就会使用主键索引
    * 2:如果包含非主键的索引就会使用非主键索引;
    * 3:如果存在多个非主键索引,会使用key_len值较小的索引
    * 为什么会有这种规律呢?
    *  -innodb非主键索引:叶子结点储存的是:索引+主键
    *   主键索引叶子结点储存的是:主键+表数据
    *    在1page里面,非主键索引可以存储更多的条目,对于一张表,假如拥有10000000数据
    *    使用非主键索引,扫描page 500,主键索引 100  非主键索引扫描的条目多,可以减少扫描的次数
    *
    **/
select count(*) from table

例2:

    /**
     * count(字段) 只会针对该字段进行统计,使用这个字段上的索引(如果包含索引的情况)
     * count(子段) 会排出字段值为null的数据
     * count(*) 不会排出字段值为null的数据
     * count(*) 和 count(1) 没有区别
     * 对于MyISAM引擎,如果 count(*) 没有where条件,查询效率会特别的快,因为把数据存储到MyISAM引擎里了
     * 对于MySQL 8.0.13,InnoDB引擎,如果count(*) 没有where条件查询速度,也是特别的快,做出了相应的优化
     *
     *
    **/
select count(某个字段) from table 会把此字段的值为null过滤掉,仅仅只统计字段值不为null的

例3:

    //做完本条查询,去执行count的操作

    select sql_calc_found_rows * from table limit 0,10;
    select found_rows() as count ;  通过此sql来获取count的结果(须在终端进行执行)

缺点在mysql8.0.17这种用法已经被废弃,未来会被永久删除

例4:

// 优点不操作具体的表,无论表的数据量有多大,都可以迅速执行. 
// 缺点:统计的是一个估算值,适合要求统计数的精度不是太高的场景    
select * from information_schema.TABLES
    where
       TABLE_SCHEMA='数据库名称'
    and
       TABLE_NAME ='表的名称';

例5:

// 优点不操作具体的表,无论表的数据量有多大,都可以迅速执行. 
// 缺点:统计的是一个估算值,适合要求统计数的精度不是太高的场景  
show table status where NAME='表的名称隔行'

例6:

// 优点不操作具体的表,无论表的数据量有多大,都可以迅速执行. 
// 缺点:统计的是一个估算值,适合要求统计数的精度不是太高的场景 
explain select * from table

例7:

优化案例; 目前有一张数量非常大的表,需要统计id值大于100的有多少条

一般写法:

select count(*) from table where id>100;

mysql8.18版:

逆向思维的写法:

select count()-(select count() from table where id <100) from table

order by 的优化: 原则利用索引,避免排序

 //first_name,last_name已经在表里创建了组合索引,emp_no为主键;

例1:

//此sql是不能利用到索引的,原因是:mysql的优化器,是根据成本计算的,如果全表扫描比使用索引,成本更低时会使用全表扫描
//如何鉴定是否使用索引避免了排序呢? 通过explain 查看sql的性能如果Extra的值为null时,说明是可以通过索引避免排序的.如果Extra的值是Using filesort 是不可以进行索引排序的
select * from table order by first_name,last_name;

//此sql可以使用索引避免排序的
select * from table order by first_name,last_name limit 10;

//此sql可以使用索引避免排序的
/**
  *[Bader,last_name,emp_no]
  *[Bader,last_name,emp_no]
  *[Bader,last_name,emp_no]
  *[Bader,last_name,emp_no]
  *
**/
select * from table where fist_name='Bader' order by last_name;



//此sql可以使用索引避免排序的
/**
  *[Bader,last_name,emp_no]
  *[Ba,last_name,emp_no]
  *[Bad,last_name,emp_no]
  *[Bade,last_name,emp_no]
  *
**/
select * from table where fist_name<'Bader' order by last_name


//此sql可以使用索引避免排序的
 select * from table where fist_name='Bader' and last_name>'Peng' order by last_name


 //此sql可以使用索引避免排序的,原因排序的俩个字段,分别存在俩个索引中
 select * from table  order by first_name,emp_no;

索引失效的场景:

1: join 字段的类型不一致

2: 在=号的左边,进行加减操作

阿里规约一般join的表数,最好不要超过三张表; 如果超过的话就要就行做相应的拆分.

例1:

select * from employees e
left join dept_emp de on e.emp_no=de.emp_no
left join departments d on de.dept_no=d.dept_no
where e.emp_no=1001;

拆分后:

select * from employees where emp_no='1001';
select * from dept_emp where emp_no='1001';
select * from departments where dept_no='d005';

表的设计原则(三范式):
一范式:表的字段都是原子性,即每个表的字段都是不可分割的,不是集合,数组,记录等非原子数据项
二范式:在第一范式的基础上,每一行数据的唯一性,非主键字段要完全依赖于主键字段.
三范式:在满足第二范式的基础上,不能存在传递依赖

原文链接:
https://css.dandelioncloud.cn/article/details/1412232643810512897



Tags:sql   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
MySQL 核心模块揭秘
server 层会创建一个 SAVEPOINT 对象,用于存放 savepoint 信息。binlog 会把 binlog offset 写入 server 层为它分配的一块 8 字节的内存里。 InnoDB 会维护自己的 savepoint...【详细内容】
2024-04-03  Search: sql  点击:(6)  评论:(0)  加入收藏
原来 SQL 函数是可以内联的!
介绍在某些情况下,SQL 函数(即指定LANGUAGE SQL)会将其函数体内联到调用它的查询中,而不是直接调用。这可以带来显著的性能提升,因为函数体可以暴露给调用查询的规划器,从而规划器...【详细内容】
2024-04-03  Search: sql  点击:(4)  评论:(0)  加入收藏
如何正确选择NoSQL数据库
译者 | 陈峻审校 | 重楼Allied Market Research最近发布的一份报告指出,业界对于NoSQL数据库的需求正在持续上升。2022年,全球NoSQL市场的销售额已达73亿美元,预计到2032年将达...【详细内容】
2024-03-28  Search: sql  点击:(14)  评论:(0)  加入收藏
MySQL 核心模块揭秘,你看明白了吗?
为了提升分配 undo 段的效率,事务提交过程中,InnoDB 会缓存一些 undo 段。只要同时满足两个条件,insert undo 段或 update undo 段就能被缓存。1. 关于缓存 undo 段为了提升分...【详细内容】
2024-03-27  Search: sql  点击:(11)  评论:(0)  加入收藏
MySQL:BUG导致DDL语句无谓的索引重建
对于5.7.23之前的版本在评估类似DDL操作的时候需要谨慎,可能评估为瞬间操作,但是实际上线的时候跑了很久,这个就容易导致超过维护窗口,甚至更大的故障。一、问题模拟使用5.7.22...【详细内容】
2024-03-26  Search: sql  点击:(10)  评论:(0)  加入收藏
从 MySQL 到 ByteHouse,抖音精准推荐存储架构重构解读
ByteHouse是一款OLAP引擎,具备查询效率高的特点,在硬件需求上相对较低,且具有良好的水平扩展性,如果数据量进一步增长,可以通过增加服务器数量来提升处理能力。本文将从兴趣圈层...【详细内容】
2024-03-22  Search: sql  点击:(24)  评论:(0)  加入收藏
在 SQL 中写了 in 和 not in,技术总监说要炒了我……
WHY?IN 和 NOT IN 是比较常用的关键字,为什么要尽量避免呢?1、效率低项目中遇到这么个情况:t1表 和 t2表 都是150w条数据,600M的样子,都不算大。但是这样一句查询 &darr;select *...【详细内容】
2024-03-18  Search: sql  点击:(6)  评论:(0)  加入收藏
应对慢SQL的致胜法宝:7大实例剖析+优化原则
大促备战,最大的隐患项之一就是慢SQL,对于服务平稳运行带来的破坏性最大,也是日常工作中经常带来整个应用抖动的最大隐患,在日常开发中如何避免出现慢SQL,出现了慢SQL应该按照什...【详细内容】
2024-03-14  Search: sql  点击:(5)  评论:(0)  加入收藏
MySQL自增主键一定是连续的吗?
测试环境:MySQL版本:8.0数据库表:T (主键id,唯一索引c,普通字段d)如果你的业务设计依赖于自增主键的连续性,这个设计假设自增主键是连续的。但实际上,这样的假设是错的,因为自增主键不...【详细内容】
2024-03-10  Search: sql  点击:(6)  评论:(0)  加入收藏
准线上事故之MySQL优化器索引选错
1 背景最近组里来了许多新的小伙伴,大家在一起聊聊技术,有小兄弟提到了MySQL的优化器的内部策略,想起了之前在公司出现的一个线上问题,今天借着这个机会,在这里分享下过程和结论...【详细内容】
2024-03-07  Search: sql  点击:(28)  评论:(0)  加入收藏
▌简易百科推荐
向量数据库落地实践
本文基于京东内部向量数据库vearch进行实践。Vearch 是对大规模深度学习向量进行高性能相似搜索的弹性分布式系统。详见: https://github.com/vearch/zh_docs/blob/v3.3.X/do...【详细内容】
2024-04-03  京东云开发者    Tags:向量数据库   点击:(5)  评论:(0)  加入收藏
原来 SQL 函数是可以内联的!
介绍在某些情况下,SQL 函数(即指定LANGUAGE SQL)会将其函数体内联到调用它的查询中,而不是直接调用。这可以带来显著的性能提升,因为函数体可以暴露给调用查询的规划器,从而规划器...【详细内容】
2024-04-03  红石PG  微信公众号  Tags:SQL 函数   点击:(4)  评论:(0)  加入收藏
如何正确选择NoSQL数据库
译者 | 陈峻审校 | 重楼Allied Market Research最近发布的一份报告指出,业界对于NoSQL数据库的需求正在持续上升。2022年,全球NoSQL市场的销售额已达73亿美元,预计到2032年将达...【详细内容】
2024-03-28    51CTO  Tags:NoSQL   点击:(14)  评论:(0)  加入收藏
为什么数据库连接池不采用 IO 多路复用?
这是一个非常好的问题。IO多路复用被视为是非常好的性能助力器。但是一般我们在使用DB时,还是经常性采用c3p0,tomcat connection pool等技术来与DB连接,哪怕整个程序已经变成以...【详细内容】
2024-03-27  dbaplus社群    Tags:数据库连接池   点击:(13)  评论:(0)  加入收藏
八个常见的数据可视化错误以及如何避免它们
在当今以数据驱动为主导的世界里,清晰且具有洞察力的数据可视化至关重要。然而,在创建数据可视化时很容易犯错误,这可能导致对数据的错误解读。本文将探讨一些常见的糟糕数据可...【详细内容】
2024-03-26  DeepHub IMBA  微信公众号  Tags:数据可视化   点击:(7)  评论:(0)  加入收藏
到底有没有必要分库分表,如何考量的
关于是否需要进行分库分表,可以根据以下考量因素来决定: 数据量和负载:如果数据量巨大且负载压力较大,单一库单一表可能无法满足性能需求,考虑分库分表。 数据增长:预估数据增长...【详细内容】
2024-03-20  码上遇见你  微信公众号  Tags:分库分表   点击:(15)  评论:(0)  加入收藏
在 SQL 中写了 in 和 not in,技术总监说要炒了我……
WHY?IN 和 NOT IN 是比较常用的关键字,为什么要尽量避免呢?1、效率低项目中遇到这么个情况:t1表 和 t2表 都是150w条数据,600M的样子,都不算大。但是这样一句查询 &darr;select *...【详细内容】
2024-03-18  dbaplus社群    Tags:SQL   点击:(6)  评论:(0)  加入收藏
应对慢SQL的致胜法宝:7大实例剖析+优化原则
大促备战,最大的隐患项之一就是慢SQL,对于服务平稳运行带来的破坏性最大,也是日常工作中经常带来整个应用抖动的最大隐患,在日常开发中如何避免出现慢SQL,出现了慢SQL应该按照什...【详细内容】
2024-03-14  京东云开发者    Tags:慢SQL   点击:(5)  评论:(0)  加入收藏
过去一年,我看到了数据库领域的十大发展趋势
作者 | 朱洁策划 | 李冬梅过去一年,行业信心跌至冰点2022 年中,红衫的一篇《适应与忍耐》的报告,对公司经营提出了预警,让各个公司保持现金流,重整团队,想办法增加盈利。这篇报告...【详细内容】
2024-03-12    InfoQ  Tags:数据库   点击:(27)  评论:(0)  加入收藏
SQL优化的七个方法,你会哪个?
一、插入数据优化 普通插入:在平时我们执行insert语句的时候,可能都是一条一条数据插入进去的,就像下面这样。INSERT INTO `department` VALUES(1, &#39;研发部(RD)&#39;, &#39...【详细内容】
2024-03-07  程序员恰恰  微信公众号  Tags:SQL优化   点击:(20)  评论:(0)  加入收藏
站内最新
站内热门
站内头条