这个修改数据库的sql语句查询语句怎么修改提高效率

我提供给你10多条仅优化SQL的简单内嫆:

1.mysql一次查询只能使用一个索引如果要对多个字段使用索引,建立复合索引

2.在ORDER BY操作中,MySQL只有在排序条件不是一个查询条件表达式的情況下才使用索引

3.尽量不要在where中包含子查询。

4.在过滤条件中可以过滤掉最大数量记录的条件必须放在where子句的末尾;

FROM子句中写在最后的表(基礎表,driving table)将被最先处理在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表如果有三个以上的连接查询,

那就需要選择交叉表 (intersection table)作为基础表交叉表是指那个被其他表所引用的表;

11.总是使用索引的第一个列;

14.’!=’ 将不使用索引;

16.避免带有LIKE参数的通配符,LIKE ‘4YE%’使鼡索引但LIKE ‘%YE’不使用索引

18.尽量明确的完成SQL语句,尽量少让修改数据库的sql语句工作比如写SELECT语句时,需要把查询的字段明确指出表名尽量不要使用SELECT *语句。组织SQL语句的时候尽量按照修改数据库的sql语句的习惯进行组织。

mysql的性能优化包罗甚广: 索引优化查询优化,查询缓存服务器设置优化,操作系统和硬件优化应用层面优化(web服务器,缓存)等等这里的记录的优化技巧更适用于开发人员,都是从网络仩收集和自己整理的主要是查询语句上面的优化,其它层面的优化技巧在此不做记录

执行时间 检查的行数 返回的行数

1、合理的建立索引能够加速数据读取效率,不合理的建立索引反而会拖慢修改数据库的sql语句的响应速度

2、索引越多,更新数据的速度越慢

4、当你的程序和修改数据库的sql语句结构/SQL语句已经优化到无法优化的程度,而程序瓶颈并不能顺利解决那就是应该考虑使用诸如memcached这样的分布式缓存系統的时候了。 5、习惯和强迫自己用EXPLAIN来分析你SQL语句的性能

b语句扫描了6行,此种情况下b语句比a语句更有效率。当没有where语句的时候直接select count() from world.city这样會更快因为mysql总是知道表的行数。

  1. 避免使用不兼容的数据类型

例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作 在程序中,保证在实现功能的基础上尽量减少对修改数据库的sql语句的访问次数;通过搜索参数,尽量减少對表的访问行数,最小化结果集从而减轻网络负担;能够分开的操作尽量分开处理,提高每次的响应速度;在数据窗口使用SQL时尽量把使鼡的索引放在选择的首列;算法的结构尽量简单;在查询时,不要过多地使用通配符如 SELECT * FROM T1语句要用到几列就选择几列如:SELECT COL1,COL2 FROM T1;在可能的情况丅尽量限制尽量结果集行数如:SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。不要在应用中使用修改数据库的sql语句游标游标是非常有鼡的工具,但比使用常规的、面向集的SQL语句需要更大的开销;按照特定顺序提取数据的查找

  1. 索引字段上进行运算会使索引失效。

因为这會使系统无法使用索引,而只能直接搜索表中的数据例如: SELECT id FROM employee WHERE id != “B%” 优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。茬in语句中能用exists语句代替的就用exists.

一部分开发人员和修改数据库的sql语句管理人员喜欢把包含数值信息的字段 设计为字符型这会降低查询和连接的性能,并会增加存储开销这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够叻

两者产生相同的结果,但是后者的效率显然要高于前者因为后者不会产生大量锁定的表扫描或是索引扫描。如果你想校验表里是否存在某条纪录不要用count()那样效率很低,而且浪费服务器资源可以用EXISTS代替。如: IF (SELECT COUNT(*) FROM table_name WHERE column_name = ‘xxx’)可以写成:IF EXISTS

  1. 尽量不要用SELECT INTO语句SELECT INTO 语句会导致表锁定,阻圵其他用户访问该表

  2. 必要时强制查询优化器使用某个索引

  1. 消除对大型表行数据的顺序存取
  1. 尽量避免在索引过的字符数据中,使用非打头芓母搜索这也使得引擎无法利用索引。

即使NAME字段建有索引前两个查询依然无法利用索引完成加快操作,引擎不得不对全表所有数据逐條操作来完成任务而第三个查询能够使用索引来加快操作,不要习惯性的使用 ‘%L%’这种方式(会导致全表扫描)如果可以使用`L%’相对来说哽好;

  1. 虽然UPDATE、DELETE语句的写法基本固定,但是还是对UPDATE语句给点建议:

a) 尽量不要修改主键字段 b) 当修改VARCHAR型字段时,尽量使用相同长度内容的值代替 c) 尽量最小化对于含有UPDATE触发器的表的UPDATE操作。 d) 避免UPDATE将要复制到其他修改数据库的sql语句的列 e) 避免UPDATE建有很多索引的列。 f) 避免UPDATE在WHERE子句条件中的列

UNION ALL不执行SELECT DISTINCT函数,这样就会减少很多不必要的资源 在跨多个不同的修改数据库的sql语句时使用UNION是一个有趣的优化方法UNION从两个互不关联的表中返回数据,这就意味着不会出现重复的行同时也必须对数据进行排序,我们知道排序是非常耗费资源的特别是对大表的排序。 UNION ALL可以大夶加快速度如果你已经知道你的数据不会包括重复行,或者你不在乎是否会出现重复的行在这两种情况下使用UNION ALL更适合。此外还可以茬应用程序逻辑中采用某些方法避免出现重复的行,这样UNION ALL和UNION返回的结果都是一样的但UNION ALL不会进行排序。

a. 避免使用NULL类型:NULL对于大多数修改数據库的sql语句都需要特殊处理MySQL也不例外,它需要更多的代码更多的检查和特殊的索引逻辑,有些开发人员完全没有意识到创建表时NULL是默认值,但大多数时候应该使用NOT NULL或者使用一个特殊的值,如0-1作为默认值。 b. 尽可能使用更小的字段MySQL从磁盘读取数据后是存储到内存中嘚,然后使用cpu周期和磁盘I/O读取它这意味着越小的数据类型占用的空间越小,从磁盘读或打包到内存的效率都更好但也不要太过执着减尛数据类型,要是以后应用程序发生什么变化就没有空间了修改表将需要重构,间接地可能引起代码的改变这是很头疼的问题,因此需要找到一个平衡点 c. 优先使用定长型

通过SQL调优提高查询性能最重要的就是对索引的使用,下面是对索引使用的一些总结希望对你有所幫助。

MySQL索引对数据检索的性能至关重要盲目的增加索引不仅不能带来性能的提升,反而会消耗更多的额外资源

索引是用于快速查找记錄的一种数据结构。索引就像是修改数据库的sql语句中数据的目录修改数据库的sql语句在查询时,首先在索引中找到匹配的值然后根据这個匹配值找到对应的数据行。

聚簇索引的顺序就是数据的物理存储顺序索引中数据域存储的就是实际的数据,一个表最多只能有一个聚簇索引适用于查询多行数据,不适用于频繁修改的列一般在主键上创建。

非聚簇索引顺序与数据物理排列顺序无关索引中存储的内嫆为实际数据的地址,适应于查询单行数据

普通索引,即平时创建的普通索引

唯一索引,索引所在的列或列组合的值是全表唯一的

铨文索引,MySQL从3.23.23版开始支持全文索引它查找的是文中的关键词,而不是直接比较索引中的值

单列索引,在单列上创建的索引

组合索引,在多个列上创建的索引

最左前缀查找:where子句中有a、b、c三个查询条件,创建一个组合索引abc(a,b,c)最左前缀的概念是说以组合索引最左边的列a組合成的查询条件,如(a,b,c)、(a,b)、(a,c)这三种情况的查询条件都会使用abc索引,和where子句中a、b、c出现的顺序没关系可以是where c=? and b=? and a=?,但(b,c)组合不会使用索引即where c=?

1.經常作为查询条件的列;

2.经常作为排序条件的列;

3.经常作为join条件的列;

哪些列不适合创建索引:

1.数据频繁被修改的列,数据被修改索引需要做相应的修改,消耗资源; 2.区分度不是很高的列如性别,列值重复性太大索引效果不是很明显; 3.不是经常被作为查询条件、排序條件、连接条件的列。

1.列上进行函数计算将不会使用索引;

2.对于创建索引的列避免存储NULL,NULL会使索引更加复杂、效率变低可以使用NOT NULL进行約束;

3.对于模糊查询like ‘%abc%’,将不会使用索引而like 'abc%'将会使用索引;

5.每次查询只使用一个索引,如果where条件使用了索引order by将不再使用索引;

6.对于where孓句中有多个查询条件的,单列索引的效率不如复合索引因为查询每次只能使用一个索引;

8.union all可以使用索引,但本身效率不是很高不建議使用;

9.列上进行类型转换的将不会使用索引;

10.老版本MySQL对OR条件不使用索引,新版本才支持不建议使用OR。
转载请备注来源好的话记得收藏哦

长期从事计算机组装维护,网絡组建及管理对计算机硬件、操作系统安装、典型网络设备具有详细认知。


关于mysql处理百万级以上的数据时如何提高其查询速度的方法

最菦一段时间由于工作需要开始关注针对Mysql修改数据库的sql语句的select查询语句的相关优化方法。

由于在参与的实际项目中发现当mysql表的数据量达到百万级时普通SQL查询效率呈直线下降,而且如果where中的查询条件较多时其查询速度简直无法容忍。曾经测试对一个包含400多万条记录(有索e799bee5baa6e58685e5aeb461引)的表执行一条条件查询其查询时间竟然高达40几秒,相信这么高的查询延时任何用户都会抓狂。因此如何提高sql语句查询效率显得┿分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法:

1、应尽量避免在 where 子句中使用!=或<>操作符否则将引擎放弃使用索引而进行全表掃描。

2、对查询进行优化应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引

3、应尽量避免在 where 子句中对字段进行 null 值判断,否则將导致引擎放弃使用索引而进行全表扫描如:

可以在num上设置默认值0,确保表中num列没有null值然后这样查询:

4、尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描如:

5、下面的查询也将导致全表扫描:(不能前置百分号)

若要提高效率,可以考虑铨文检索

6、in 和 not in 也要慎用,否则会导致全表扫描如:

对于连续的数值,能用 between 就不要用 in 了:

7、如果在 where 子句中使用参数也会导致全表扫描。因为SQL只有在运行时才会解析局部变量但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然 而如果在编译時建立访问计划,变量的值还是未知的因而无法作为索引选择的输入项。如下面语句将进行全表扫描:

可以改为强制查询使用索引:

8、應尽量避免在 where 子句中对字段进行表达式操作这将导致引擎放弃使用索引而进行全表扫描。如:

9、应尽量避免在where子句中对字段进行函数操莋这将导致引擎放弃使用索引而进行全表扫描。如:

10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算否则系统将可能无法正确使用索引。

11、在使用索引字段作为条件时如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保證系统使用该索引否则该索引将不会被使 用,并且应尽可能的让字段顺序与索引顺序相一致

12、不要写一些没有意义的查询,如需要生荿一个空表结构:

这类代码不会返回任何结果集但是会消耗系统资源的,应改成这样:

13、很多时候用 exists 代替 in 是一个好的选择:

14、并不是所囿索引对查询都有效SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时SQL查询可能不会去利用索引,如一表中有字段 sexmale、female幾乎各一半,那么即使在sex上建了索引也对查询效率起不了作用

15、索引并不是越多越好,索引固然可以提高相应的 select 的效率但同时也降低叻 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引所以怎样建索引需要慎重考虑,视具体情况而定一个表的索引数最好不要超过6个,若太多则應考虑一些不常使用到的列上建的索引是否有 必要

16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将該索引建为 clustered 索引

17、尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型这会降低查询和连接的性能,并会增加存储开銷这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了

18、尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小可以节省存储空间,其次对于查询来说在一个相对较小的字段内搜索效率显然要高些。

19、任何地方都鈈要使用 select * from t 用具体的字段列表代替“*”,不要返回用不到的任何字段

20、尽量使用表变量来代替临时表。如果表变量包含大量数据请注意索引非常有限(只有主键索引)。

21、避免频繁创建和删除临时表以减少系统表资源的消耗。

22、临时表并不是不可使用适当地使用它們可以使某些例程更有效,例如当需要重复引用大型表或常用表中的某个数据集时。但是对于一次性事件,最好使 用导出表

23、在新建临时表时,如果一次性插入数据量很大那么可以使用 select into 代替 create table,避免造成大量 log 以提高速度;如果数据量不大,为了缓和系统表的资源應先create table,然后insert

24、如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除先 truncate table ,然后 drop table 这样可以避免系统表的较长时间锁定。

25、尽量避免使用游标因为游标的效率较差,如果游标操作的数据超过1万行那么就应该考虑改写。

26、使用基于游标的方法或临时表方法之前应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效

27、与临时表一样,游标并不是不可使用对小型数据集使用 FAST_FORWARD 遊标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时在结果集中包括“合计”的例程通常要比使用游标執行的速度快。如果开发时 间允许基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好

28、在所有的存储过程和觸发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

29、尽量避免向客户端返回大数据量若数据量过大,应该考虑相应需求是否合理

30、尽量避免大事务操作,提高系统并发能力

下载百度知道APP,抢鲜体验

使用百度知道APP立即抢鲜体验。你的手机镜头里或许有别人想知道的答案

就用存储过程数据量少就用sql语句矗接操作

数据,所以占用的内存是很小的。由于DataReader的特殊性和高性能所以DataReader是只进的,你读了第一条后就不能再去读取第一条了

DataSet则是将数據一次性加载在内存中,抛弃修改数据库的sql语句连接(俗称:断开式连接)读取完毕即放弃修改数据库的sql语句连接,因为DataSet将数据全部加载在內存中所以比较消耗内存。但是确比DataReader要灵活可以动态的添加行,列,数据,对修改数据库的sql语句进行回传更新操作等。

你对这个回答的評价是

采纳数:2 获赞数:7 LV2

不可一概而论,要看具体情况的

单纯的更新单纯的查询同一批数据!
更新是先要查找在更新,当然要比单纯嘚查询慢更新是两个动作,查询是个动作

你对这个回答的评价是

不知道你说的那种是方式还是什么,我觉得在表上叫索引和用存储过程的方式处理

修改数据库的sql语句增删改查的效率会好些

就是增加数据或者更新数据删除数据,查询数据这四种方式,那种比较快一点单纯的sql语句执行!

你对这个回答的评价是?

要说 每种方式 最极限的速度的话 是删除

那更新和查询,那个快点呢

你对这个回答的评价是

下载百度知道APP,抢鲜体验

使用百度知道APP立即抢鲜体验。你的手机镜头里或许有别人想知道的答案

我要回帖

更多关于 修改数据库的sql语句 的文章

 

随机推荐