精华内容
下载资源
问答
  • 在使用msyql进行模糊查询的时候,很自然的会用到like语句,通常情况下,在数据量小的时候,不容易看出查询的效率,但在数据量达到百万级,千万级的时候,查询的效率就很容易显现出来。这个时候查询的效率就显得很...

    在使用msyql进行模糊查询的时候,很自然的会用到like语句,通常情况下,在数据量小的时候,不容易看出查询的效率,但在数据量达到百万级,千万级的时候,查询的效率就很容易显现出来。这个时候查询的效率就显得很重要!

    一般情况下like模糊查询的写法为(field已建立索引):

    SELECT`column`FROM`table`WHERE`field`like'%keyword%';

    上面的语句用explain解释来看,SQL语句并未用到索引,而且是全表搜索,如果在数据量超大的时候,可想而知最后的效率会是这样

    对比下面的写法:

    SELECT`column`FROM`table`WHERE`field`like'keyword%';

    这样的写法用explain解释看到,SQL语句使用了索引,搜索的效率大大的提高了!

     

    但是有的时候,我们在做模糊查询的时候,并非要想查询的关键词都在开头,所以如果不是特别的要求,"keywork%"并不合适所有的模糊查询

    我在网上搜索时发现很多mysql函数用来解决这个问题,我测试出来的结果是跟like相比并没有任何优势。

    1.LOCATE('substr',str,pos)方法

    SELECT`column`FROM`table`WHERELOCATE('keyword', `field`)>0

    2.POSITION('substr' IN `field`)方法

    SELECT`column`FROM`table`WHEREPOSITION('keyword'IN`filed`)

    3.INSTR(`str`,'substr')方法

    SELECT`column`FROM`table`WHEREINSTR(`field`,'keyword')>0

    这几种方法都试过后,发现百万级别数据以上,时间是跟like差不多,并没有解决问题,因为都没走到索引。

    这种情况下想要实现后几位模糊查询并且速度要快,在此我想了两个办法,一个是不需要mysql版本支持,一个需要mysql5.7版本以上,我测试的数据都是200W条数据以上的。

     

    第一种方法:新增一列字段,那个字段是你需要实现模糊查询的倒序,也就是原本是ABCD,那列字段就是DCBA

    然后在那个字段添上索引

    UPDATE tbl_ser_apply a set order_no_desc = REVERSE (SUBSTRING(a.order_no, -6))

    ALTER TABLE `tbl_ser_apply` ADD INDEX order_no_desc ( `order_no_desc` )

    我这边设的是后六位  也就是我把之前字段的后6位倒序后存入新的字段,也可以整个字段倒序后存入新的字段

    select a.*,a1.id as id2,a1.order_no as orderNo2,a1.tran_amt as tranAmt2,a1.fee_amt as feeAmt2,a1.repayment_date_req as repaymentDateReq2

      ,a1.status as status2,a1.create_time as createTime2,a1.update_time as updateTime2

      from (

      select tsa.id,tsa.order_no as orderNo,tsa.repayment_date_req as repaymentDateReq,tsa.`status`,tsa.fee_state as feeState,tsa.repayment_flag as repaymentFlag,

      tsa.capital_return_flag as capitalReturnFlag,tsa.tran_amt as tranAmt,tsa.fee_amt as feeAmt,tsa.capital_returned_amont as capitalReturnedAmont,

      tsa.wait_amt as waitAmt,tsa.back_charge_amt as backChargeAmt,tsa.create_time as createTime,tui.real_name as realName,tui.mobile_no as mobileNo,

      tc.bank_card_no as bankCardNo,tmi.merchant_name as merchantName,tui.mer_no as merNo,tsa.reserved1 as reserved1,tsa.parent_id as parentId,tc.bank_name as bankName,tc.holder_name as holderName,

      tc.certificate_no as certificateNo

      from tbl_ser_apply as tsa LEFT JOIN tbl_user_info as tui on tsa.userid=tui.id LEFT JOIN tbl_merchant_inf as tmi on

      tmi.merchant_no=tui.mer_no  LEFT JOIN tbl_cusinfo tc on tc.id=tsa.cusInf_id where tsa.order_no_desc like  REVERSE('%372191')

      ORDER BY tsa.create_time desc ) a  LEFT JOIN tbl_ser_apply a1 on  a.parentId=a1.id

    我的整个sql是这样的

    实际上最后查询的时候是这样

    where tsa.order_no_desc like  REVERSE('%372191')

    相当于是查询你新增字段,sql上加上reverse函数,这样子%就在后面,而且能实现整个字段的模糊查询

    这种做法需要修改sql和java代码,查询的是新增反向字段,而不是原来的字段

    这样就能实现走索引

    原来的sql不走索引的情况下查询出来需要20S,优化后只需要0.049S

    这种方法适合mysql5.7以下版本,这样能大大加快模糊查询速度,而且能到1000W以上应该都是没问题的

    第二种方法需要mysql5.7以上版本支持,用到虚拟列的方法,原理跟上述方法一样

    新增一列虚拟列,用函数索引计算你需要模糊查询的字段

    新增函数索引虚拟列,将虚拟列添加索引

    alter table tbl_ser_apply add column virtual_col varchar(20) as (REVERSE (SUBSTRING(tbl_ser_apply.order_no, -6)));

    ALTER TABLE `tbl_ser_apply` ADD INDEX  virtual_col ( ` virtual_col` )

    在MySQL 5.7中,支持两种Generated Column,即Virtual Generated Column和Stored Generated Column,前者只将Generated Column保存在数据字典中(表的元数据),并不会将这一列数据持久化到磁盘上;后者会将Generated Column持久化到磁盘上,而不是每次读取的时候计算所得。很明显,后者存放了可以通过已有数据计算而得的数据,需要更多的磁盘空间,与Virtual Column相比并没有优势,因此,MySQL 5.7中,不指定Generated Column的类型,默认是Virtual Column。

    如果需要Stored Generated Golumn的话,可能在Virtual Generated Column上建立索引更加合适

    综上,一般情况下,都使用Virtual Generated Column,这也是MySQL默认的方式

     

    语法:

    [ GENERATED ALWAYS ] AS ( ) [ VIRTUAL|STORED ]

    [ UNIQUE [KEY] ] [ [PRIMARY] KEY ] [ NOT NULL ] [ COMMENT ]

    这样做比上一个方法好的地方是,不需要修改java代码,只需要修改很小一部分的sql语句即可,上一个方法其实实现后要修改的java代码要不少,而且每次新增修改删除时,都要加上这个字段的代码,而新增虚拟列的话,那一列的字段是自动添加修改,通过计算得出的,所以代码完全不需要修改,只需要修改操作原来字段的sql即可。

    select a.*,a1.id as id2,a1.order_no as orderNo2,a1.tran_amt as tranAmt2,a1.fee_amt as feeAmt2,a1.repayment_date_req as repaymentDateReq2

      ,a1.status as status2,a1.create_time as createTime2,a1.update_time as updateTime2

      from (

      select tsa.id,tsa.order_no as orderNo,tsa.repayment_date_req as repaymentDateReq,tsa.`status`,tsa.fee_state as feeState,tsa.repayment_flag as repaymentFlag,

      tsa.capital_return_flag as capitalReturnFlag,tsa.tran_amt as tranAmt,tsa.fee_amt as feeAmt,tsa.capital_returned_amont as capitalReturnedAmont,

      tsa.wait_amt as waitAmt,tsa.back_charge_amt as backChargeAmt,tsa.create_time as createTime,tui.real_name as realName,tui.mobile_no as mobileNo,

      tc.bank_card_no as bankCardNo,tmi.merchant_name as merchantName,tui.mer_no as merNo,tsa.reserved1 as reserved1,tsa.parent_id as parentId,tc.bank_name as bankName,tc.holder_name as holderName,

      tc.certificate_no as certificateNo

      from tbl_ser_apply as tsa LEFT JOIN tbl_user_info as tui on tsa.userid=tui.id LEFT JOIN tbl_merchant_inf as tmi on

      tmi.merchant_no=tui.mer_no  LEFT JOIN tbl_cusinfo tc on tc.id=tsa.cusInf_id where tsa.virtual_col like  '372191%'

      ORDER BY tsa.create_time desc ) a  LEFT JOIN tbl_ser_apply a1 on  a.parentId=a1.id

    这是我新增虚拟列后的查询语句,同样也是查询的虚拟列的字段。

    相当于查的是这个where tsa.virtual_col like  '372191%',这样也能实现%在后面,也就能走索引。

    经过我的测试后,原来不走索引是20S 用第一种方法是0.049s 用第二种方法的话是0.1S  虽然慢了0.05S 那是计算数据的时间,但这样的方案已经大大缩短了模糊查询时间,而且不需要修改java代码,个人推荐使用第二种!

    展开全文
  • 问题:明明建立了索引,为何Like模糊查询速度还是特别慢? Like是否使用索引?  1、like %keyword 索引失效,使用全表扫描。但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引,不走全表扫描。 ...
  • Oracle 模糊查询优化

    千次阅读 2013-08-06 19:20:20
    模糊查询是数据库查询中经常用到的,一般常用的格式如下: (1)字段 like '%关键字%'  字段包含"关键字“的记录 即使在目标字段建立索引也不会走索引,速度最慢  (2)字段 like '关键字%' 字段以"关键字...

    模糊查询是数据库查询中经常用到的,一般常用的格式如下:

    (1)字段  like '%关键字%'   字段包含"关键字“的记录   即使在目标字段建立索引也不会走索引,速度最慢  

    (2)字段  like '关键字%'      字段以"关键字"开始的记录   可以使用到在目标字段建立的升序索引

    (3)字段 like '%关键字'      字段以"关键字“结束的记录    可以使用到目标字段建立的降序索引


    对于无法使用索引的 '%关键字%' 模式,有没有办法优化呢,答案是肯定的,

    在ORacle中提供了instr(strSource,strTarget)函数,比使用'%关键字%'的模式效率高很多。

    instr函数说明:

    INSTR

      (源字符串, 目标字符串, 起始位置, 匹配序号)

      在Oracle/PLSQL中,instr函数返回要截取的字符串在源字符串中的位置。只检索一次,就是说从字符的开始

      到字符的结尾就结束。

      语法如下:

      instr( string1, string2 [, start_position [, nth_appearance ] ] )

      参数分析:

      string1

      源字符串,要在此字符串中查找。

      string2

      要在string1中查找的字符串.

      start_position

      代表string1 的哪个位置开始查找。此参数可选,如果省略默认为1. 字符串索引从1开始。如果此参数为正,从左到右开始检索,如果此参数为负,从右到左检索,返回要查找的字符串在源字符串中的开始索引。

      nth_appearance

      代表要查找第几次出现的string2. 此参数可选,如果省略,默认为 1.如果为负数系统会报错。

      注意:

      如果String2在String1中没有找到,instr函数返回0.

      示例:

      SELECT instr('syranmo','s') FROM dual; -- 返回 1

      SELECT instr('syranmo','ra') FROM dual;  -- 返回 3

      1 SELECT instr('syran mo','a',1,2) FROM dual;  -- 返回 0

    模糊查询优化:

    了解了instr函数的用法,优化就变得简单了,例如 %关键字%   等同于  instr(字段,'关键字')>0

    经过我的简单测试,instr函数比like %关键字% 大概快一倍。

    展开全文
  • 采用全文索引解决模糊查询速度慢的问题 上一篇 / 下一篇 2009-09-22 20:58:34 查看( 281 ) / 评论( 2 ) / 评分( 8 / 0 ) 转自http://sandish.itpub.net/post/4899/464369   众所周知,使用 like 进行模糊查询...

    采用全文索引解决模糊查询速度慢的问题

    上一篇 /下一篇  2009-09-22 20:58:34

    转自http://sandish.itpub.net/post/4899/464369

     

    众所周知,使用 like 进行模糊查询速度极差,包括 like 'AAA%' ,like '%AAA',like '%AAA%',like '%A%A%'以及采用“_”进行单字符匹配的那些模糊查询。网上有很多文章讲到如何提高like查询,提到 like 'AAA%'能够使用到索引,而like '%AAA' ,使用创建反向函数的索引来提高查询效率。但一般情况下,是无法约定客户端采用哪种like查询,难道说把所有的这些情况都进行if判断吗?

    为这个事情脑袋疼了无数次。最近,一客户“无理”要求对用户地址模糊查询速度太慢。在数十万的用户记录下查询,要求5秒之内必须查询到记录。

    想破脑袋还是找不到方法。有同事找了本Lucene的书给我看,说是能解决。翻来覆去的看了2,3遍,始终想不出这玩意儿怎么用。

    突然想到oracle也有全文索引一说,以前只是别人提起过这个词。与网上朋友一聊,说是似乎可以解决,但他忘了怎么用了。

    半夜12点,赶紧爬起来,到google上查资料。还真有两下子,研究了几个小时,有所获。第二天白天没时间研究,晚上继续,最终把全文索引搞定,解决了模糊查询速度慢的问题,在数十万条用户数据中, 对用户地址进行模糊查询速度在2秒以内就能够查到。

    -------------------------------------------------------------------------

    以下是创建全文索引的方法(网上有文章提到使用图形化界面,我用图形化界面创建全文索引,创建了一个晚上,第二天起床居然还没完。但用SQL命令15分钟左右就搞定):

    对cmng_custominfo 表中的address字段做全文检索:
    1,在oracle9201中需要创建一个分词的东西:

    BEGIN
    ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');
    --ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用
    end;

    2,创建全文检索:

    CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');

    3,查询时候,使用:

    select * from cmng_custominfo where contains (address, '金色新城')>1;

    自己测试,发现select * from cmng_custominfo where contains (address, '%金色新城%')>1;才能实现模糊查询,并且使用了索引,数据库版本为oracle9.0.1.1.1

    4,需要定期进行同步和优化:
    同步:根据新增记录的文本内容更新全文搜索的索引。

    begin
    ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');
    end;

    优化:根据被删除记录清除全文搜索索引中的垃圾

    begin
    ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');
    end;

    5,采用job做步骤4中的工作:

    1)该功能需要利用oracle的JOB功能来完成
    因为oracle9I默认不启用JOB功能,所以首先需要增加ORACLE数据库实例的JOB配置参数:
    job_queue_processes=5
    重新启动oracle数据库服务和listener服务。

    2)同步 和 优化
    --同步 sync:
    variable jobno number;
    BEGIN
    DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');', SYSDATE, 'SYSDATE + (1/24/4)');
     commit;
    END;

    --优化
    variable jobno number;
    begin
     DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');
     commit;
    END;

    其中, 第一个job的SYSDATE + (1/24/4)是指每隔15分钟同步一次,第二个job的SYSDATE + 1是每隔1天做一次全优化。具体的时间间隔,可以根据应用的需要而定

    6,索引重建
    重建索引会删除原来的索引,重新生成索引,需要较长的时间。
    重建索引语法如下:
    ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;

    据网上一些用家的体会,oracle重建索引的速度也是比较快的,有一用家这样描述:

    Oracle 的全文检索建立和维护索引要比ms sql server都要快得多,笔者的65万记录的一个表建立索引只需要20分钟,同步一次只需要1分钟。
    因此,也可以考虑用job的办法定期重建索引。

    参考资料:
    1,http://blog.csdn.net/yurenjia/archive/2007/04/08/1556306.aspx
    2,http://topic.csdn.net/u/20080117/23/34004f4a-4989-47ef-8764-0b7e3bf737a7.html
    3,http://tenwe.com/tech/database/oracle/200702/content_561_4.shtml
    4,http://www.knowsky.com/389357.html
    5,http://yangtingkun.itpub.net/post/468/195520
    6,http://bbs.zdnet.com.cn/archiver/tid-120474.html
    7,http://bbs.违规广告.com/archiver/tid-26270.html
    8,http://oracle.**.com/exploiture/720104_3.html
    9,http://www.33kuai.cn/html/shujuku/20080126/5314_2.html
    10,http://www.xrss.cn/Dev/DataBase/20084218963.Html

    展开全文
  • 模糊查询like优化

    2019-01-28 09:10:32
    原sql语句:select project_ name from project_info where project_name like "...所以采用另一种机制,为project_name建立索引,从索引表中模糊匹配索引值去查询索引值。 原sql语句中我只需要project_nam...

    原sql语句:select project_ name from project_info where project_name like "%北京%"

    1.建立索引(最为有效)

    我们都知道,因为索引最左前缀匹配原则,全模糊匹配,sql是不走索引的。

    所以采用另一种机制,为project_name建立索引,从索引表中模糊匹配索引值去查询索引值。

    原sql语句中我只需要project_name,因此为project_name建立索引,形成“表”,因此只从索引表中取速率更快。

    通过explain后查询得到sql语句走的是 index索引查询

    如果需要查询多个字段,例如sql

    select project_name,project_code from project_info where project_name like "%北京%"

    可以建立联合索引,为project_code,project_name建立联合索引,这样依旧从索引表中取需要的字段,速度必然快

    从一开始的6.3秒变为0.248秒

    2.instr()方法截取字符串

    sql:select project_name from project_info where instr(project_name,"北京") >0

    instr()相当于截取字符串,用时4.9秒

    展开全文
  • 现在查询部分做优化查询车号的like模糊查询对应时间段查询很慢,短时间段内数据量不要太多还可以,如果好几百万数据中差就非常慢啦。 不知各位大侠高手们有什么比较成熟项目成果可以分享,或者从服务器WEB环境...
  • Mybatis:like模糊查询性能优化

    千次阅读 2019-04-08 12:00:43
    正常like模糊查询所用时间。 使用INSTR所用时间
  • 众所周知,使用 like 进行模糊查询速度极差,包括 like 'AAA%' ,like '%AAA',like '%AAA%',like '%A%A%'以及采用“_”进行单字符匹配的那些模糊查询。网上有很多文章讲到如何提高like查询,提到 like 'AAA%'能够...
  • ORACLE模糊查询优化浅谈

    千次阅读 2016-09-25 19:28:13
    模糊查询是数据库查询中经常用到的,一般常用的格式如下: (1)字段 like '%关键字%' 字段包含"关键字“的记录 即使在目标字段建立索引也不会走索引,速度最慢 (2)字段 like '关键字%' 字段以"关键字...
  • 表结构如下:title是有索引 mysql5.7: 执行sql解析如下:不走索引 ...走了索引,虽然是扫面的全表行数,但是查询效率是不加索引的10几倍,下面是对比测试 走索引数据查询时间 SELECT id,title ...
  • 最近老大给了一个需求,是要写一个姓名的模糊查询。 问题很简单,难度在于这张表有将近500W条数据。 如果要做中文的模糊查询,效率简直惨不忍睹。 网上查了一下资料,发现全文索引挺符合我的需要的。 结果,使用...
  • like语句(全/右)模糊查询优化 优化思路: 1)因为like 'xxx%' 形式是可以用索引的,所以将like '%xxx%' 转为 正反值的like 'xxx%' ; 2)利用冗余数据解决速度问题; 1、原始SQL SELECT COUNT('*') AS `__count` ...
  • 为了能够对液压凿岩机钻进速度进行有效的优化控制,深入地研究了模糊自适应PID控制技术在其中的应用。分析了液压凿岩机的钻进速度优化控制机理;研究了模糊自适应PID控制器的基本原理;探讨了液压凿岩机钻进速度优化...
  • 大数据量模糊查询优化

    千次阅读 2014-02-18 17:19:44
    SQL Server数据库查询技巧一:  问题类型:ACCESS数据库字段中含有日文片假名或其它不明字符时查询会提示内存溢出。  解决方法:修改查询语句  sql="select * from ada where alice like '%"&abigale&"%'" 改...
  • 基于OpenLayers 的WFS模糊查询优化

    千次阅读 2011-07-18 18:17:05
    思路:先通过指定一个featureName字段,在全表查询时,返回的数据就会比较小,这样会提高一些速度。返回数据中,我们取出featureid的值,再通过url进行GML格式的解析,从而得到查询后返回的全字段GML信息。 实现...
  • MySQL优化查询速度的方法

    千次阅读 2019-04-14 11:47:30
    查询速度慢的原因 从程序员的角度 查询语句写的不好 没建索引,索引建的不合理或索引失效 关联查询有太多的join 从服务器的角度 服务器磁盘空间不足 服务器调优配置参数设置不合理 MySQL数据库优化的八种方式 ...
  • sql优化之like模糊查询【亲测】

    万次阅读 2018-02-22 20:21:09
    一、工作心得:优化也好,升级也罢,做web开发,安全重于泰山。只有数据安全了,才可以谈优化。 二、关于索引: Oracle B-tree、位图、全文索引三大索引性能比较及优缺点罗列一下 1、B-Tree索引 场合:非常适合...
  • 数据库索引之优化查询速度

    千次阅读 2018-05-23 21:32:22
    (一)索引的作用 索引通俗来讲就相当于书的...提升查询速度的方向一是提升硬件(内存、cpu、硬盘),二是在软件上优化(加索引、优化sql)。 (二)mysql的索引类型: mysql的索引有5种:主键索引、普通索引、唯一...
  • [经验之谈]数据库查询速度优化之解决技巧

    万次阅读 多人点赞 2016-09-11 13:11:42
    在上篇文章漫谈数据库查询速度优化方案我们讲到了,数据优化的几种方案,现在这篇文章,我们就实际来看看,如何实际到具体的操作上.也就是我们在写数据时我们应该注意些什么. 1、对查询进行优化,应尽可能避免全表扫描 ...
  • 模糊搜索优化

    2018-05-26 19:51:26
    今天来说一下模糊搜索的优化测试经常在开发中经常有会用到模糊搜索的 地方 最常见的就是 商品搜索。 关键字搜索等等接下来我们来看一条语句SELECT * FROM `DEMO` WHERE `FIELD` LIKE%KEYWORD%;这是一条模糊搜索的...
  • 针对异构无线网络的接入选择问题,在考虑用户业务类型和网络状态的前提...实验结果表明,利用蜻蜓算法优化模糊神经网络能够提高模糊神经网络的收敛速度,提高系统吞吐量,降低接入阻塞率,并在一定程度上减少切换次数。
  • 为提高矿井提升机故障诊断的准确率,提出了一种基于优化模糊Petri网的矿井提升机故障诊断新方法。该方法首先利用动量BP网络对模糊Petri网的权值、阈值和可信度参数进行优化,然后使用优化好的模糊Petri网模型对矿井...
  • oracle模糊查询效率提高 博客分类:  oracle 数据库 模糊查询 内存 技术札记   分2种思路考虑模糊查询的效率的提高。--注:专注处理百万级数据量,小量数据就算了 第一种:把数据存到业务内存中,通过查询...
  • 数据库查询速度优化之解决技巧

    千次阅读 2018-08-22 11:25:59
    1、对查询进行优化,应尽可能避免全表扫描 首先应考虑在 where 及 order by 涉及的列上建立索引。  下面我们来以一个表中177条数据比较一下,全表扫描与建立索引之后性能的一个比较. 1.1 全表查询 1.2 建立...
  • 为了更准确地描述有记忆效应的射频功放特性,提出了一种改进的简化粒子群优化(PSO)算法,并结合自适应模糊推理系统(ANFIS)建立模糊神经网络功放模型。改进的简化PSO算法仅保留粒子的位置项,加入了随机的个体最优候选解...
  • 如何优化Mysql执行查询数据的速度

    千次阅读 2016-03-11 16:58:42
    在项目中数据量小的情况下使用like查询速度还行,但是随着数据一天一天增加,再使用like进行模糊查询的时候速度上就会显得比较慢,现提供两套解决方案: 问题: 使用like查询效率很慢 select inner_id,title from...
  • 针对现有基于核方法的直觉模糊聚类算法对初始值敏感、收敛速度慢等缺陷,利用粒子群优化算法全局搜索能力强、收敛速度快的优势,对直觉模糊核聚类算法的初始聚类中心进行优化,并提出了一种基于粒子群优化的直觉模糊...
  • 提出基于混沌粒子群优化加权模糊聚类的旋转机械故障诊断算法.该算法用混沌粒子群算法取代传统的梯度下降法,优化...应用表明,混沌粒子群算法有效提高了模糊聚类分析的收敛速度和精度,提高了旋转机械故障诊断的准确率.

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 52,533
精华内容 21,013
关键字:

优化模糊查询的速度