大数据的特点主要包括哪些?
500
2024-04-26
随着数字化时代的到来,大数据已经成为企业发展和运营的重要资产之一。然而,随之而来的挑战是,大数据的存储和处理往往给数据库带来了巨大压力,导致性能下降和效率降低。因此,针对大数据下的数据库优化显得尤为重要。
在传统的数据库优化中,我们通常会关注索引的建立、查询语句的优化、表的设计等方面,但在面对大数据时,这些方法显然已经不再适用。因此,需要针对大数据的特点和需求,制定专门的优化策略。
首先,大数据的存储量巨大,传统的存储方式已经无法满足需求。在处理海量数据时,数据库的读写效率成为了最大的瓶颈。此外,大数据往往具有高并发的特点,需要数据库具备更高的并发处理能力。除此之外,大数据的多样性也给数据库的数据结构带来了挑战,传统的关系型数据库已经无法满足对多样化数据的存储和查询需求。
因此,在大数据下的数据库优化过程中,需要考虑以下几个方面:
针对大数据下的数据库优化,以下是一些有效的优化策略:
采用分布式存储系统是在大数据场景下常见的优化方式之一。通过将数据分布在多个节点上,避免了单点存储的瓶颈问题,提高了读写效率和系统的可扩展性。同时,分布式存储系统还可以提供数据的冗余备份,保证数据的安全性和可靠性。
在处理大数据时,往往需要不断扩展数据库的处理能力。通过水平扩展的方式,即增加数据库节点的方式,可以有效提高数据库的并发处理能力,降低单节点的压力,提高系统的稳定性和可靠性。
在大数据场景下,往往存在一些数据是经常被访问和修改的“热数据”,而有些数据则很少被访问的“冷数据”。针对这种情况,可以将热数据和冷数据分开存储,对于热数据采用高性能的存储系统,而对于冷数据可以采用低成本的存储方案,从而在保证性能的同时降低成本。
大数据的存储量通常十分庞大,数据压缩是一种有效的优化手段。通过对数据进行压缩,可以减少存储空间的占用,降低存储成本,同时在数据传输和备份过程中也可以减少时间和成本的消耗。
数据分区是一种常见的数据库优化策略,特别适用于大数据场景。通过将数据进行分区存储,可以提高数据的访问效率,降低查询的成本,同时可以根据业务需求动态调整数据的分区策略,保证系统的性能和稳定性。
在大数据时代,数据库优化是保证数据处理效率和系统稳定性的重要手段。针对大数据下的数据库优化,我们需要根据数据的特点和需求,制定专门的优化策略,包括存储优化、并发优化、查询优化等方面。只有不断优化数据库系统,才能更好地应对大数据带来的挑战,实现数据驱动的业务发展和创新。
化总结如下:1、主键就是聚集索引2、只要建立索引就能显著提高查询速度3、把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度注意事项1. 不要索引常用的小型表2. 不要把社会保障号码(SSN)或身份证号码(ID)选作键3. 不要用用户的键4. 不要索引 memo/notes 字段和不要索引大型文本字段(许多字符)5. 使用系统生成的主键
无论什么数据库,大的方面都是这三种吧:
1,数据库配置优化
2,数据库建表时字段设置优化以及字段属性的设置要最合适。
3,sql查询语句优化。
在CentOS系统中,使用Oracle数据库是一项常见的任务。无论是管理数据库的状态,还是优化数据库的性能,都是至关重要的。本文将介绍如何在CentOS系统下,监控和管理Oracle数据库的状态,并提供一些建议来优化数据库的性能,以确保其正常运行并提高效率。
首先,了解Oracle数据库的当前状态是十分重要的。通过使用Oracle Enterprise Manager或者SQL*Plus工具,可以轻松地监控数据库的运行状态、性能指标和活动会话信息。数据库管理员可以查看表空间使用情况、数据库连接数、CPU和内存利用率等重要信息,以便及时发现并解决潜在的问题。 此外,也可以借助Oracle Diagnostics Pack提供的性能分析工具,对数据库进行深入的性能分析,找出潜在的瓶颈和性能问题。
除了监控数据库状态,优化数据库性能也是至关重要的。以下是一些优化建议:
通过监控数据库状态,及时发现潜在问题,并通过优化数据库性能,可以保证Oracle数据库在CentOS系统下的稳定运行和高效工作。
最后,希望本文对您在CentOS下使用Oracle数据库的状态监控和性能优化提供了一些帮助。谢谢您的阅读!
需要学校或者研究机构购买全文下载权限,通常高校都会购买,所以可以从高校的网络下载
在当今数字化时代,大数据已经成为许多行业中不可或缺的一部分。随着数据量不断增加,如何高效且快速地存储和管理这些海量数据,成为了每个企业都必须面对的挑战。数据库的优化是解决这个问题的关键。
大数据数据库优化是指通过调整数据库的结构、查询语句的编写和索引的设计等手段,提高大数据处理效率和性能的过程。一个有效的数据库优化策略可以极大地提升数据处理速度,减少资源消耗并改善数据的可用性。
大数据处理通常涉及海量数据的读取、写入和分析。如果数据库结构设计不当或查询语句效率低下,将导致系统的响应时间变慢、数据分析结果不准确且资源消耗巨大。正确地进行数据库优化能够解决这些问题,提升大数据处理的效率和质量。
下面将介绍几个常用的大数据数据库优化策略和技巧:
在大数据处理中,数据库的设计和规划是非常重要的一步。首先,需要根据业务需求和数据特点选择合适的数据库类型,例如关系型数据库或非关系型数据库。其次,合理设计数据表的结构,减少冗余字段,优化数据存储方式。此外,对于大数据而言,分布式数据库和集群架构也是必要的考虑因素。
优化查询语句是大数据数据库优化中的关键步骤之一。编写高效的查询语句可以减少数据库的负载,提升查询速度和响应时间。避免使用不必要的通配符查询、避免使用子查询或联合查询等复杂操作,优化常用查询语句并合理使用索引等技巧都是提高查询效率的方法。
在大数据数据库中,合理地设计索引是提高查询效率的关键。根据业务需求和查询频率,选择合适的字段建立索引。对于频繁进行排序和分组操作的字段,也需要考虑创建索引以提高查询速度。此外,定期维护和优化索引是保持数据库性能稳定的重要手段。
对于大数据量的数据库,采用数据分区和分片技术能够将数据分散存储在不同的物理位置上,从而提高数据的处理速度和并发性能。通过合理地划分数据区域,可以减少查询的范围,提升查询效率,同时降低单个节点的负载。
在大数据环境中,数据库的高可用性和容灾能力也是至关重要的。及时备份数据并建立冗余备份,可以保证在系统故障或数据丢失的情况下,能够快速恢复数据并保证业务的连续性。使用故障切换和多活部署等容灾机制,可以有效降低系统故障对业务的影响。
虽然大数据数据库优化可以带来许多好处,但实施过程中也面临着一些挑战。
大数据往往具有多种格式和类型的数据,包括结构化数据和非结构化数据。如何处理和存储这些多样性和复杂性的数据,是数据库优化中的一个难点。
大数据数据库通常需要处理实时、流式的数据。在快速写入和更新的同时,保持数据的一致性和完整性是一个挑战。数据库优化需要考虑到这一点,确保数据的准确性和可靠性。
大数据数据库中存储着大量的敏感信息,安全和隐私保护是至关重要的。数据库优化的过程中,需要采取合适的安全策略和措施,保障数据的安全性和隐私。
随着技术的不断发展和创新,大数据数据库优化也将朝着以下方向发展:
未来的大数据数据库优化将更加智能化和自动化。通过机器学习和人工智能等技术,数据库系统可以自动识别和调整查询语句、优化索引和分区策略,从而提升数据库性能。
分布式计算是大数据处理的重要手段之一。未来的数据库优化将更加注重分布式计算的技术,将数据分散存储在不同的节点上,并利用分布式计算框架进行并发处理,提高系统的可伸缩性和性能。
数据流式处理是处理实时数据的有效方法。未来的数据库优化将更加注重数据流式处理的技术,通过实时处理和分析数据流,提供实时决策支持。
大数据数据库优化是提升大数据处理效率和性能的重要手段。通过合理的数据库设计、优化查询语句、精心设计的索引和分区等策略,可以提高数据库的响应速度,减少资源消耗。然而,在实施优化过程中也面临着一些挑战,如数据的多样性和复杂性、数据一致性和安全保护。未来的数据库优化将朝着智能化、分布式计算和数据流式处理等方向发展。
`图数据库(Graph database)`` 并非指存储图片的数据库,而是以图这种数据结构存储和查询数据。
图形数据库是一种在线数据库管理系统,具有处理图形数据模型的创建,读取,更新和删除(CRUD)操作。
与其他数据库不同, 关系在图数据库中占首要地位。这意味着应用程序不必使用外键或带外处理(如MapReduce)来推断数据连接。
与关系数据库或其他NoSQL数据库相比,图数据库的数据模型也更加简单,更具表现力。
图形数据库是为与事务(OLTP)系统一起使用而构建的,并且在设计时考虑了事务完整性和操作可用性。
SQL提高查询效率
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在where及orderby涉及的列上建立索引。
2.应尽量避免在where子句中对字段进行null值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
selectidfromtwherenumisnull
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
selectidfromtwherenum=0
3.应尽量避免在where子句中使用!=或操作符,否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在where子句中使用or来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
selectidfromtwherenum=10ornum=20
可以这样查询:
selectidfromtwherenum=10
unionall
selectidfromtwherenum=20
5.in和notin也要慎用,否则会导致全表扫描,如:
selectidfromtwherenumin(1,2,3)
对于连续的数值,能用between就不要用in了:
selectidfromtwherenumbetween1and3
6.下面的查询也将导致全表扫描:
selectidfromtwherenamelike'%abc%'
若要提高效率,可以考虑全文检索。
7.如果在where子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
selectidfromtwherenum=@num
可以改为强制查询使用索引:
selectidfromtwith(index(索引名))wherenum=@num
8.应尽量避免在where子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
selectidfromtwherenum/2=100
应改为:
selectidfromtwherenum=100*2
9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:
selectidfromtwheresubstring(name,1,3)='abc'--name以abc开头的id
selectidfromtwheredatediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
selectidfromtwherenamelike'abc%'
selectidfromtwherecreatedate>='2005-11-30'andcreatedate
10.不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询,如需要生成一个空表结构:
selectcol1,col2into#tfromtwhere1=0
这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:
createtable#t(...)
13.很多时候用exists代替in是一个好的选择:
selectnumfromawherenumin(selectnumfromb)
用下面的语句替换:
selectnumfromawhereexists(select1frombwherenum=a.num)
14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好,索引固然可以提高相应的select的效率,但同时也降低了insert及update的效率,因为insert或update时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新clustered索引数据列,因为clustered索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新clustered索引数据列,那么需要考虑是否应将该索引建为clustered索引。
17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
18.尽可能的使用varchar/nvarchar代替char/nchar,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用select*fromt,用具体的字段列表代替“*”,不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
21.避免频繁创建和删除临时表,以减少系统表资源的消耗。
22.临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。
23.在新建临时表时,如果一次性插入数据量很大,那么可以使用selectinto代替createtable,避免造成大量log,以提高速度;如果数据量不大,为了缓和系统表的资源,应先createtable,然后insert。
24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先truncatetable,然后droptable,这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。
27.与临时表一样,游标并不是不可使用。对小型数据集使用FAST_FORWARD游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置SETNOCOUNTON,在结束时设置SETNOCOUNTOFF。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC消息。
29.尽量避免大事务操作,提高系统并发能力。
30.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理
1、避免将字段设为“允许为空”
2、数据表设计要规范
3、深入分析数据操作所要对数据库进行的操作
4、尽量不要使用临时表
5、多多使用事务
6、尽量不要使用游标
7、避免死锁
8、要注意读写锁的使用
9、不要打开大的数据集
10、不要使用服务器端游标
11、在程序编码时使用大数据量的数据库
12、不要给“性别”列创建索引
13、注意超时问题
14、不要使用Select*
15、在细节表中插入纪录时,不要在主表执行SelectMAX(ID)
16、尽量不要使用TEXT数据类型
17、使用参数查询
18、不要使用Insert导入大批的数据
19、学会分析查询
20、使用参照完整性
21、用INNERJOIN和LEFTJOIN代替Where
提高SQL查询效率(要点与技巧):
·技巧一:
问题类型:ACCESS数据库字段中含有日文片假名或其它不明字符时查询会提示内存溢出。
解决方法:修改查询语句
sql="select*fromtablenamewherecolumnlike'%"&word&"%'"
改为
sql="select*fromtablename"
rs.filter="columnlike'%"&word&"%'"
===========================================================
技巧二:
问题类型:如何用简易的办法实现类似百度的多关键词查询(多关键词用空格或其它符号间隔)。
解决方法:
'//用空格分割查询字符串
ck=split(word,"")
'//得到分割后的数量
sck=UBound(ck)
sql="select*tablenamewhere"
在一个字段中查询
Fori=0Tosck
SQL=SQL&tempJoinWord&"("&_
"columnlike'"&ck(i)&"%')"
tempJoinWord="and"
Next
在二个字段中同时查询
Fori=0Tosck
SQL=SQL&tempJoinWord&"("&_
"columnlike'"&ck(i)&"%'or"&_
"column1like'"&ck(i)&"%')"
tempJoinWord="and"
Next
===========================================================
技巧三:大大提高查询效率的几种技巧
1.尽量不要使用or,使用or会引起全表扫描,将大大降低查询效率。
2.经过实践验证,charindex()并不比前面加%的like更能提高查询效率,并且charindex()会使索引失去作用(指sqlserver数据库)
3.columnlike'%"&word&"%'会使索引不起作用
columnlike'"&word&"%'会使索引起作用(去掉前面的%符号)
(指sqlserver数据库)
4.'%"&word&"%'与'"&word&"%'在查询时的区别:
比如你的字段内容为一个容易受伤的女人
'%"&word&"%':会通配所有字符串,不论查“受伤”还是查“一个”,都会显示结果。
'"&word&"%':只通配前面的字符串,例如查“受伤”是没有结果的,只有查“一个”,才会显示结果。
5.字段提取要按照“需多少、提多少”的原则,避免“select*”,尽量使用“select字段1,字段2,字段3........”。实践证明:每少提取一个字段,数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。
6.orderby按聚集索引列排序效率最高。一个sqlserver数据表只能建立一个聚集索引,一般默认为ID,也可以改为其它的字段。
7.为你的表建立适当的索引,建立索引可以使你的查询速度提高几十几百倍。(指sqlserver数据库)
·以下是建立索引与不建立索引的一个查询效率分析:
Sqlserver索引与查询效率分析。
表News
字段
Id:自动编号
Title:文章标题
Author:作者
Content:内容
Star:优先级
Addtime:时间
记录:100万条
测试机器:P42.8/1G内存/IDE硬盘
=======================================================
方案1:
主键Id,默认为聚集索引,不建立其它非聚集索引
select*fromNewswhereTitlelike'%"&word&"%'orAuthorlike'%"&word&"%'orderbyIddesc
从字段Title和Author中模糊检索,按Id排序
查询时间:50秒
=======================================================
方案2:
主键Id,默认为聚集索引
在Title、Author、Star上建立非聚集索引
select*fromNewswhereTitlelike'"&word&"%'orAuthorlike'"&word&"%'orderbyIddesc
从字段Title和Author中模糊检索,按Id排序
查询时间:2-2.5秒
=======================================================
方案3:
主键Id,默认为聚集索引
在Title、Author、Star上建立非聚集索引
select*fromNewswhereTitlelike'"&word&"%'orAuthorlike'"&word&"%'orderbyStardesc
从字段Title和Author中模糊检索,按Star排序
查询时间:2秒
=======================================================
方案4:
主键Id,默认为聚集索引
在Title、Author、Star上建立非聚集索引
select*fromNewswhereTitlelike'"&word&"%'orAuthorlike'"&word&"%'
从字段Title和Author中模糊检索,不排序
查询时间:1.8-2秒
=======================================================
方案5:
主键Id,默认为聚集索引
在Title、Author、Star上建立非聚集索引
select*fromNewswhereTitlelike'"&word&"%'
或
select*fromNewswhereAuthorlike'"&word&"%'
从字段Title或Author中检索,不排序
查询时间:1秒
·如何提高SQL语言的查询效率?
问:请问我如何才能提高SQL语言的查询效率呢?
答:这得从头说起:
由于SQL是面向结果而不是面向过程的查询语言,所以一般支持SQL语言的大型关系型数据库都使用一个基于查询成本的优化器,为即时查询提供一个最佳的执行策略。对于优化器,输入是一条查询语句,输出是一个执行策略。
一条SQL查询语句可以有多种执行策略,优化器将估计出全部执行方法中所需时间最少的所谓成本最低的那一种方法。所有优化都是基于用记所使用的查询语句中的where子句,优化器对where子句中的优化主要用搜索参数(SerachArgument)。
搜索参数的核心思想就是数据库使用表中字段的索引来查询数据,而不必直接查询记录中的数据。
带有=、、>=等操作符的条件语句可以直接使用索引,如下列是搜索参数:
emp_id="10001"或salary>3000或a=1andc=7
而下列则不是搜索参数:
salary=emp_salary或dep_id!=10或salary*12>=3000或a=1orc=7
应当尽可能提供一些冗余的搜索参数,使优化器有更多的选择余地。请看以下3种方法:
第一种方法:
selectemployee.emp_name,department.dep_namefromdepartment,employeewhere(employee.dep_id=department.dep_id)and(department.dep_code="01")and(employee.dep_code="01");
它的搜索分析结果如下:
Estimate2I/Ooperations
Scandepartmentusingprimarykey
forrowswheredep_codeequals"01"
Estimategettinghere1times
Scanemployeesequentially
Estimategettinghere5times
第二种方法:
selectemployee.emp_name,department.dep_namefromdepartment,employeewhere(employee.dep_id=department.dep_id)and(department.dep_code="01");
它的搜索分析结果如下:
Estimate2I/Ooperations
Scandepartmentusingprimarykey
forrowswheredep_codeequals"01"
Estimategettinghere1times
Scanemployeesequentially
Estimategettinghere5times
第一种方法与第二种运行效率相同,但第一种方法最好,因为它为优化器提供了更多的选择机会。
第三种方法:
selectemployee.emp_name,department.dep_namefromdepartment,employeewhere(employee.dep_id=department.dep_id)and(employee.dep_code="01");
这种方法最不好,因为它无法使用索引,也就是无法优化……
使用SQL语句时应注意以下几点:
1、避免使用不兼容的数据类型。例如,Float和Integer,Char和Varchar,Binary和LongBinary不兼容的。数据类型的不兼容可能使优化器无法执行一些本可以进行的优化操作。例如:
selectemp_nameformemployeewheresalary>3000;
在此语句中若salary是Float类型的,则优化器很难对其进行优化,因为3000是个整数,我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。
2、尽量不要使用表达式,因它在编绎时是无法得到的,所以SQL只能使用其平均密度来估计将要命中的记录数。
3、避免对搜索参数使用其他的数学操作符。如:
selectemp_namefromemployeewheresalary*12>3000;
应改为:
selectemp_namefromemployeewheresalary>250;
4、避免使用!=或等这样的操作符,因为它会使系统无法使用索引,而只能直接搜索表中的数据。
·ORACAL中的应用
一个1600万数据表--短信上行表TBL_SMS_MO
结构:
CREATETABLETBL_SMS_MO
(
SMS_IDNUMBER,
MO_IDVARCHAR2(50),
MOBILEVARCHAR2(11),
SPNUMBERVARCHAR2(20),
MESSAGEVARCHAR2(150),
TRADE_CODEVARCHAR2(20),
LINK_IDVARCHAR2(50),
GATEWAY_IDNUMBER,
GATEWAY_PORTNUMBER,
MO_TIMEDATEDEFAULTSYSDATE
);
CREATEINDEXIDX_MO_DATEONTBL_SMS_MO(MO_TIME)
PCTFREE10
INITRANS2
MAXTRANS255
STORAGE
(
INITIAL1M
NEXT1M
MINEXTENTS1
MAXEXTENTSUNLIMITED
PCTINCREASE0
);
CREATEINDEXIDX_MO_MOBILEONTBL_SMS_MO(MOBILE)
PCTFREE10
INITRANS2
MAXTRANS255
STORAGE
(
INITIAL64K
NEXT1M
MINEXTENTS1
MAXEXTENTSUNLIMITED
PCTINCREASE0
);
问题:从表中查询某时间段内某手机发送的短消息,如下SQL语句:
SELECTMOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROMTBL_SMS_MO
WHEREMOBILE='130XXXXXXXX'
ANDMO_TIMEBETWEENTO_DATE('2006-04-01','YYYY-MM-DDHH24:MI:SS')ANDTO_DATE('2006-04-07','YYYY-MM-DDHH24:MI:SS')
ORDERBYMO_TIMEDESC
返回结果大约需要10分钟,应用于网页查询,简直难以忍受。
分析:
在PL/SQLDeveloper,点击“ExplainPlan”按钮(或F5键),对SQL进行分析,发现缺省使用的索引是IDX_MO_DATE。问题可能出在这里,因为相对于总数量1600万数据来说,都mobile的数据是很少的,如果使用IDX_MO_MOBILE比较容易锁定数据。
如下优化:
SELECT/*+index(TBL_SMS_MOIDX_MO_MOBILE)*/MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROMTBL_SMS_MO
WHEREMOBILE='130XXXXXXXX'
ANDMO_TIMEBETWEENTO_DATE('2006-04-01','YYYY-MM-DDHH24:MI:SS')ANDTO_DATE('2006-04-07','YYYY-MM-DDHH24:MI:SS')
ORDERBYMO_TIMEDESC
测试:
按F8运行这个SQL,哇~......2.360s,这就是差别。
http://www.cnblogs.com/ShaYeBlog/archive/2013/07/31/3227244.html
不要用delete,可以尝试用下列办法 drop table tblname; -- 彻底删除该表 truncate table tblname; -- 快速删除数据,但是保存数据结构
使用数据库优化清理插件