[20190524]浅谈模糊查询.txt
--//一台生产系统遇到监听进程莫名down的情况,3月份曾经遇到的情况,链接:http://blog.itpub.net/267265/viewspace-2638863/
--//当时的分析:内存不足(机器内存4G相对偏小),磁盘IO不足,sql语句没有很好优化,没有使用hugepages。
--//实际上最本质的问题是SQL语句，这套系统已经运行6年以上，里面一些sql采用模糊查询也就是使用like '%姓名%'之类的查询条件.
--//首先提一下监听进程莫名down的问题，该版本10.2.0.4有1个bug,导致监听down掉.要打p6139856_10204_Linux-x86-64.zip补丁.
--//实际上这个bug一般出现在内存不足CPU资源不足的情况下才会激发。
1.关于模糊查询:
--//实际上这套系统上线我就针对这个问题提出自己的建议，开发往往拿用户的需求搪塞，从用户角度讲，确实需要这样的功能.
--//比如像姓名的模糊查询，操作用户难道不知道查询的姓吗？非也，实际上大部分情况下是知道的，最多的情况下就是一些姓不会读
--//或者读不对，还有就是拼音开头是z,c,s,zh,ch,sh,j之类的翻许多页能找到(注：大部分操作人员使用紫光拼音),一些经常打的字自
--//动调整到前面）。所以讲操作人员输入姓不会打的概率很低。完全没有必要千篇一律的查询like '%姓名%'。
--//再比如查询体检编号的问题，也是使用模糊查询，这套系统是体检系统，为了与住院病人编号相互区别。编码时在开头加入'tj'标识.
--//开发为了体验用户操作的方便，也是使用模糊查询，也就是不用输入tj也可以查询。而实际上操作用户根本不领你这个情,查询条件
--//都是like '%tjNNNNN%',我一扫描共享池就能看到这样的情况。
2.我的建议：
--//实际就是给模糊查询设置一点门槛。
--//就是在边上设计一个按钮,选上就是模糊查询,执行条件变成类似就是like '%姓名%'的模糊查询，不选就是like '姓名%'的查询。这
--//样等于给用户增加一点点"难度"。而且随着数据量增加，操作人员会慢慢体会模糊查询的"很慢".
--//还有一种方式就是让操作人员直接输入%作为模糊查询,仅仅在一些地方提示用户如何操作就ok了，这样改动更小，仅仅在于一点点操
--//作人员的培训,让他们知道如何输入查询条件。
3.给开发建议：
--//从我个人角度讲我很少提出无法完成的工作，或者工作量很大的改动，即使我发现一些设计不合理，如果改动过大，我基本不提。
--//就是提也都是浪费时间。
--//有时候我想是不是开发根本不知道还是故意而为之,这样的改动很难吗？像这样的系统即使我改用hugepages，也就是支撑1,2年.
--//说不定根本撑不到那个时间，硬件已经坏了。我见过许多项目如果从性能优化或者可持续运行角度讲.基本上属于豆腐渣工程。
--//更加不能理解的是，用户最终会把这些问题莫名其妙的问题归到网络信息中心... 无语...
--//也许拯救整个系统最好的选择就是购买更好的硬件，来掩盖软件设计开发的缺陷，良好的硬件就是一块遮羞布，如此反复出现。