MariaDb SQL查询性能 注意事项

where,on和order by指定的字段要有索引

复杂计算的结果应在生成后写入 而不是每次读取时计算,除非写的成本大于读

除了分页以外 避免出现count(*)的情况 count数据用一个count字段在写入时累加 判断是否存在使用有短路机制的exists()函数

避免出现使用sum()的情况,应建立单独的表写入时累加相应结果

任何情况下都应该避免使用not in(),应使用in()、exists()、not exists()和union查询代替

in()当中不能包含SQL查询,如果需要包含查询则用exists()函数和等价的条件代替

任何情况下都应该避免使用外连查询,应使用内连查询+多条SQL查询代替。

时间: 2024-12-23 10:55:01

MariaDb SQL查询性能 注意事项的相关文章

sql查询性能分析

SQL查询性能分析 http://blog.csdn.net/dba_huangzj/article/details/7623926 五分钟打造自己的sql性能分析工具 http://www.cnblogs.com/gezifeiyang/p/3403744.html sql查询性能分析,布布扣,bubuko.com

比较SQL查询性能 语句

比较SQL查询性能 语句 --优先使用SET STATISTICS IO和SET STATISTICS TIME查看性能调节是否有效. --SET STATISTICS TIME ON --SET STATISTICS TIME ON 在开始我们的例子前,先运行下面的这二条命令(不要在正在使用的服务器上执行),这二条命令将清除SQL Server的数据和过程缓冲区,这样能够使我们在每次执行查询时在同一个起点上,否则,每次执行查询得到的结果就不具有可比性了:DBCC DROPCLEANBUFFER

聚焦-移除Bookmark Lookup、RID Lookup、Key Lookup提高SQL查询性能(六)

前言 前面几节都是讲的基础内容,本节我们讲讲索引性能优化,当对大数据进行处理时首先想到的就是索引,一旦遇到这样的问题则手忙脚乱,各种查资料,为何平常不扎实基本功呢,我们由浅入深,简短的内容,深入的理解,而非一上来就把问题给框死,立马给出解决方案,抛出问题,再到解决问题,你GET了没有. Bookmark Lookup.RID Lookup.Key Lookup定义 一说到这三者,如果对索引研究不深的童鞋估计是懵逼的,什么玩意,我们姑且将上面三者翻译为:标签查找.行ID查找.键查找.标签查找和键查

mysql经纬度查询并且计算2KM范围内附近用户的sql查询性能优化实例教程

之前很傻很天真地以为无非就是逐个计算距离,然后比较出来就行了,然后当碰到访问用户很多,而且数据库中经纬度信息很多的时候,计算量的迅速增长,能让服务器完全傻逼掉,还是老前辈的经验比我们丰富,给了我很大的启示. MySQL性能调优 – 使用更为快速的算法进行距离计算 最近遇到了一个问题,通过不断的尝试最终将某句原本占据近1秒的查询优化到了0.01秒,效率提高了100倍. 问题是这样的,有一张存放用户居住地点经纬度信息的MySQL数据表,表结构可以简化 为:id(int),longitude(long

DBA推荐的7法宝提高SQL查询性能

SQL查询数据库时,可以采取一系列的方式来提高查询的速度和性能.比如用case代替update,使用临时表和分批进行更新等.本文介绍了7种提高查询速度的方法,请读者参考. SQL查询数据库时,适当遵循一些原则可以让工作变得更加轻松,本文就列举7个可以灵活运用的原则,它们可以帮助你提高SQL查询速度,当然这些技巧你可以咨询DBA获得更多的信息. 1.用case代替update 要更新一条记录,我们立即会想到update,这个问题非常常见,许多开发人员经常忽视这个原则,因为使用update看起来非常

5种提升SQL查询性能的知识

“SQL性能优化是一种黑魔法就像炼金术一样:各种配方难解晦涩,只有一小部分圈内人才能理解.” 这是一种误解,SQL数据库使用的是大家公知的算法来实现可以预期的执行性能.然而,问题是,人们很容易写出不能发挥最高效算法的SQL查询语句,因而也容易产生无法预期的性能结果. 下面是5道关于SQL性能优化小测试题,这些测试题也许会让你坚信SQL优化就是一种黑魔法.但答案中提供的解释说明会随即让你明白,这些所谓的黑魔法其实是纯粹的科学. 本测试中使用的SQL是基于Oracle数据库. 单从性能的视角看,下面

sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME---解释比较详细

一个查询需要的CPU.IO资源越多,查询运行的速度就越慢,因此,描述查询性能调节任务的另一种方式是,应该以一种使用更少的CPU.IO资源的方式重写查询命令,如果能够以这样一种方式完成查询,查询的性能就会有所提高. 如果调节查询性能的目的是让它使用尽可能少的服务器资源,而不是查询运行的时间最短,那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性能.尤其是在资源利用不断变化的服务器上更是如此.首先,需要搞清楚在对查询进行调节时,如何测试我们的服务器的资源使用情况.        在开始

SQL 查询性能优化----解决书签查找

先来看看什么是书签查找: 当优化器所选择的非聚簇索引只包含查询请求的一部分字段时,就需要一个查找(lookup)来检索其他字段来满足请求.对一个有聚簇索引的表来说是一个键查找(key lookup),对一个堆表来说是一个RID查找(RID lookup).这种查找即是——书签查找. 书签查找根据索引的行定位器从表中读取数据.因此,除了索引页面的逻辑读取外,还需要数据页面的逻辑读取. 从索引的行定位器到从表中读取数据这之间会产生一些额外的开销,本文就来解决这个开销. 先看下我的测试表结构: 其中可

通过手动创建统计信息优化sql查询性能案例

本质原因在于:SQL Server 统计信息只包含复合索引的第一个列的信息,而不包含复合索引数据组合的信息 来源于工作中的一个实际问题, 这里是组合列数据不均匀导致查询无法预估数据行数,从而导致无法选择合理的执行计划导致性能低下的情况 我这里把问题简单化,主要是为了说明问题 如下一张业务表,主要看两个“状态”字段,BusinessStatus1 和 BusinessStatus2 create table BusinessTable ( Id int identity(1,1), Col2 va