您现在的位置是:首页 > 关键词排名关键词排名

如何进行SQL性能优化?

江湖快报网2023-05-22 22:03:23【关键词排名】人已围观

简介一、如何进行SQL性能优化?
一、使用索引
1.单表索引建议控制在5个以内
2.单索引字段数不允许超过5个因为字段超过5个时,实际已经起不到有效过滤数据的作用了。
3.禁止在更新十分

一、如何进行SQL性能优化?

一、使用索引 1.单表索引建议控制在5个以内 2.单索引字段数不允许超过5个因为字段超过5个时,实际已经起不到有效过滤数据的作用了。 3.禁止在更新十分频繁、区分度不高的属性上建立索引,因为更新会变更B+树,更新频繁的字段建立索引会大大降低数据库性能。 4.性别”这种区分度不大的属性,建立索引是没有什么意义的,不能有效过滤数据,性 能与全表扫描类似。 5.建立组合索引,必须把区分度高的字段放在前面,因为能够更加有效的过滤数据。

二、SQL使用规范优化 1.禁止使用SELECT *,只获取必要的字段,需要显示说明列属性。

1.1读取不需要的列会增加CPU、IO、NET消耗。 1.2不能有效的利用覆盖索引。 2.禁止使用INSERT INTO t_xxx VALUES(xxx),必须显示指定插入的列属性。 2.1容易在增加或者删除字段后出现程序BUG。 3.禁止使用属性隐式转换。 3.1 SELECT uid FROM t_user WHERE phone= 会导致全表扫描,而不 能命中phone索引。 4.禁止在WHERE条件的属性上使用函数或者表达式。 4.1SELECT uid FROM t_user WHERE from_unixtime(day)>='' 会导致全 表扫描。 4.2正确的写法是:SELECT uid FROM t_user WHERE day>= unix_timestamp(' 00:00:00')。 5.禁止负向查询,以及%开头的模糊查询。 5.1 负向查询条件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等,会导致全表扫描。 5.2 %开头的模糊查询,会导致全表扫描。 6.禁止大表使用JOIN查询,禁止大表使用子查询。 6.1会产生临时表,消耗较多内存与CPU,极大影响数据库性能。 7.禁止使用OR条件,必须改为IN查询。 7.1旧版本Mysql的OR查询是不能命中索引的,即使能命中索引,为何要让数据库耗费 更多的CPU帮助实施查询优化呢? 8.应用程序必须捕获SQL异常,并有相应处理 总结:大数据量高并发的互联网业务,极大影响数据库性能的都不能用哦。

二、SQL数据库优化的方法有哪些

在进行软件开发过程中,数据库的使用是非常重要的,但是数据库有很多种,不同数据库的使用方法是不同的。进行软件开发过程中,至少需要掌握一种数据库的使用方法。SQL数据库语法简单、操作方便和高效,是很多人最优的选择,但是SQL语句会受到不同数据库功能的影响,在计算时间和语言的效率上面需要举正进行优化,根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。

一、适当的索引

索引基本上是一种数据结构,有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库,但是索引太多或没有索引会导致错误的结让闷果。IT培训认为如果没有索引,处理速度会变得非常慢。

二、仅索引相关数据

指定需要检索数据的精度。使用命令*和LIMIT代替SELECT*。调整数据库时,必须使用所需的数据集而不是整个数据集,尤其是当数据源非常大时,指定所需的数据集,能够节省大部分时间。

三、根据需求使用或避免临时表

如果代码可以用简单的方式编写,那么永远不要使临时表变得复杂。当然,如果数据具有需要多个查询的特定程序,北大青鸟建议在这种情况下,使用临正滑悔时表。临时表通常由子查询交替。

四、避免编码循环

避免编码循环是非常重要的,因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环,并且昆明北大青鸟发现WHERE命令能够确保存储的数据不被更新,这样能够方便在找到匹配和预先存在的数据时被找到。

三、SQL优化万能公式:5 大步骤 + 10 个案例

在应用开发的早期,数据量兆尺键少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,困链有时可能这些有问题的SQL就是整个系统性能的瓶颈。

1、通过慢查日志等定位那些执行效率较低的SQL语句

2、explain 分析SQL的执行计划

type由上至下,效率越来越高

Extra

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的,开启语句“set profiling = 1;”

4、trace

trace分析优化器如何选择执行计划,通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

5、确定问题并采用相应的措施

案例1、最左匹配

索引

SQL语句

查询匹配从左往右匹配,要使用order_no走索引,必须查询条件携带shop_id或者索引( shop_id , order_no )调换前后顺序

案例2、隐式转换

索引

SQL语句

隐式转换相当于在索引上做运算,会让索引失效。mobile是字符类型,使用了数字,应该使用字符串匹配,否则MySQL会用到隐式替换,导致索引失效。

案例3、大分页

索引

SQL语句

对于大分页的场景,可以优先让产品优化需求,如果没有优化的,有如下两种优化方式, 一种是把上一次的最后一条数据,也即上面的c传过来,然后做“c < xxx”处理,但是这种一般需要改接口协议,并不一定可行。另一种是采用延迟关联的方式进行处理,减少SQL回表,但是要记得索引需要完全覆盖才有效果,SQL改动如下

案例4、in + order by

索引

SQL语句

in查询在MySQL底层是族巧通过n*m的方式去搜索,类似union,但是效率比union高。in查询在进行cost代价计算时(代价 = 元组数 * IO平均值),是通过将in包含的数值,一条条去查询获取元组数的,因此这个计算过程会比较的慢,所以MySQL设置了个临界值(eq_range_index_pe_limit),5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200,即in条件超过了200个数据,会导致in的代价计算存在问题,可能会导致Mysql选择的索引不准确。

处理方式,可以( order_status , created_at )互换前后顺序,并且调整SQL为延迟关联。

案例5、范围查询阻断,后续字段不能走索引

索引

SQL语句

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。(可以用到ICP)

在索引上,避免使用NOT、!=、>、!、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小,则优化器还是会选择辅助索引,但是当访问的数据占整个表中数据的蛮大一部分时(一般是20%左右),优化器会选择通过聚集索引来查找数据。

查询出所有未支付的订单,一般这种订单是很少的,即使建了索引,也没法使用索引。

案例8、复杂查询

如果是统计某些数据,可能改用数仓进行解决;如果是业务上就有那么复杂的查询,可能就不建议继续走SQL了,而是采用其他的方式进行解决,比如使用ES等进行解决。

案例9、asc和desc混用

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储,可能数据量会很大,如果在方案的选择上,最终选择存储在MySQL上,并且做7天等有效期的保存。那么需要注意,频繁的清理数据,会照成数据碎片,需要联系DBA进行数据碎片处理。

Tags:公式   万能   步骤

很赞哦! ()

文章评论

    共有条评论来说两句吧...

    用户名:

    验证码:

本站推荐