如何实现SQL的多条件模糊查询

不确定我是否明白你的意思。
由于你不知道页面会有多少“查询”，所以只能手动拆分SQL语句。
例如，页面上运行有n个“查询”。
你只能穿越。
例如，“问题”的名称值为“答案”。
在前台，您可以处理并用逗号分隔所有答案，例如“Answer1,Answer2...”Stringanswer[]=request.getParameter("anser").split(",")StringanswerVal[]=request.getParameter("answerVal").split(",")StringBuildersb=newStringBuilder();sb.append("select*fromtablewhere")for(inti=0,l=answer.length;i还有，不要直接这样写，建议使用prepareStatement，否则会发生SQL注入。
只要理解其中的想法即可。

Sql优化-多like模糊查询及根据时间排序

2020-04-21记录一条SQL优化记录：环境：使用selectVersion()的MySQL版本；使用两张表进行联合查询，四个条件作为查询，按时间降序排列，包括A表和B表；没有大字段，包括表A中的数据超过20万条，B表中的数据超过50万条。
声明如下：EXPLAINSELECTA.bondId,A.sname,A.cname,A.secuCode,A.ISSUER,A。
担保人，B.underwriterASinfoSourceFROMALEFTJOINBONB.bondId=A.bondIdWHEREB.agentType=1ANDB.underwriter='有限责任公司'ANDA.startDate<='2020-04-2118:02:10'ANDA.endDate>='2020-04-2118:02:10'AND(A.cnameLIKE'%%'ORA.snameLIKE'%%'ORA.secuCodeLIKE'%%'ORA.ISSUERLIKE'%%'ORA.guarantorLIKE'%%')ANDA.isValid=1ORDERBYA.startDateDESCLIMIT0,20这是两个表都没有索引的情况。
从解释来看，结果很糟糕。
都是全表扫描，临时表和文件同时生成。
排序肯定是非常低效的。
首先尝试对B表创建联合索引。
可以考虑从相关字段和条件字段where(bondId,underwriter,agentType)创建联合索引。
ALTERTABLEBADDINDEXbua_index(bondId,underwriter,agentType)进一步解释：可以看到B表使用了我们刚刚创建的联合索引，附加信息为Usingindex，type为reflevel，效果比较理想，我们再看看A表。
在Where条件下更喜欢。
这种情况下通用索引是不可用的，所以需要用覆盖索引来解决由于是按照startDate排序的，所以我们尝试根据以下字段创建一个通用索引同时查询的字段在索引字段（startDate、endDate、cname、sname、secuCode、发行者、保修）ALTERTABLEAADDINDEXindex_scss。
ig(startDate,endDate,cname,sname,secuCode,issuer,garantor)再次解释看看效果：乍一看，表A也使用了新创建的联合索引，类型为rangelevel虽然比ref差一些，但是显然应该可以，但是当我执行SQL语句的时候，效率还是很差查询需要8秒，偶尔会更长原因是虽然使用了索引，但是另外还有Usingindexcondition&Usingwhere表的返回操作。
我觉得如果我进一步优化Usingindex的话，效率就不成问题了，所以可以进一步优化。
我应该从索引开始，添加2个字段isValid、bondId到联合索引，然后尝试ALTERTABLEAADDINDEXindex_scssig(isvalid,startDate,endDate,cname,sname,secuCode,Issuer,guarantor,bondId)再次解释：这个结果就是我想要的，然后运行sql看看效率-提高了很多，但是当我尝试其他查询条件时，有时时间达到3.4s，我怀疑这与我的MySQL机器本身不擅长处理这些类型的点赞或多个查询有关。
我别无选择，只能这样做。
效率可能不是很高，这样优化也是可以接受的。
最近，我对之前项目中的慢查询进行了SQL优化。
我认为性能下降往往是由SQL语句和索引的创建引起的。
说明适当的优化可以大大提高效率。