• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            興海北路

            ---男兒仗劍自橫行
            <2008年11月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            30123456

            統計

            • 隨筆 - 85
            • 文章 - 0
            • 評論 - 17
            • 引用 - 0

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            收藏夾

            全是知識啊

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            mysql模糊查詢結果不準確的解決辦法
            作者: falcon   發表日期: 2006-04-15 16:07   復制鏈接



            引言:

            在執行mysql的模糊查詢操作時,發現返回的結果不準確,可至今沒有找到完善的解決方案,所以特地來尋求解決方案拉.

            問題:


            我在命令行里頭直接使用mysql(版本為mysql-4.0.18-win.zip)的時候也出現同樣問題:
            ===================================
            我有一個表里頭存放了一些文件信息,包括中文的非中文的;
            表名為file_tab,里頭的重要字段是file,存放文件名,另外該字段的類型是char

            我想查找包含"新鮮"這個詞語的所有文件
            理所當然的就用了

            select file from file_tab where file like '%新鮮%'

            執行后返回的結果卻包含了其他信息,如下:

            李湘給我新鮮
            凱瑞·路易斯·托馬斯&克利斯·馬頓-水晶頭骨之謎
            劉易斯·托馬斯-水母與蝸牛
            劉易斯·托馬斯-細胞生命的禮贊
            托馬斯-細胞生命的禮贊
            [劉易斯·托馬斯] 科學的危險
            [柳文揚] 托馬斯叔叔的推薦信
            08.新鮮

            結果明顯不符合我的本來用意

            自己分析:有可能是mysql對中文的處理問題,也許其他文件名里頭的信息對應字節信息和"新鮮"對應的字節信息存在匹配關系,所以才得到這樣不符合本來要求的結果,可是我找不到解決辦法.

            后來我以為是mysql的版本太低,從貴站下了msyql5.0.18,可是輸出結果同樣不準確,所以無奈
            麻煩大家一起探討/

            詳細見:http://bbs.mysql.cn/thread-633-1-1.html



            解決辦法:

            解決問題本身
            如果你定義該字段類型為char型,請用alter添加約束binary;
            針對我上面的問題,解決方案如下:

            先用describe file_tab查看該表的數據結構,然后通過下面的語句進行修改

            alter table file_tab modify file char(100) binary not null;

            [注:其中char(100) not null為原來的類型或約束,binary為添加的約束]

            補充,如果你定義的字段類型為其他類型,遇到類似問題,可能也是沒有加binary的緣故,試試就知道,呵呵

            不過到底還是不知道為什么要用binary哦
            所以我有去網路上找了一下,在百度里頭輸入mysql binary

            先是找到《mysql中文參考手冊》(用編輯>查找>binary,看看其作用)
            http://www.yesky.com/imagesnew/software/mysql/manual_Compatibility.html
            里頭介紹了binary的作用:

            缺省地,所有的字符串比較是忽略大小寫的,由當前的字符集決定了(缺省為ISO-8859-1 Latin1)排序順序。如果你不喜歡這樣,你應該用BINARY屬性或使用BINARY強制符聲明列,它導致根據MySQL服務器主機的ASCII順序進行排序。

            后來竟然找到和我問題一樣的東東:
            《MySQL中文模糊檢索問題的解決方法》
            http://down.dl.net.cn/Article.asp?id=605
            我的天啊,竟然有這么詳細的解決辦法

            解決附帶問題,實現不區分大小寫查詢

            但是仔細一看,用binary后,竟然區分大小寫拉

            因此在查找的時候很不方便

            那么我們該怎么辦呢?

            上面的文章中提到了解決辦法,但在文末尾提到了這樣會影響一些速度
            那怎么盡量消除這個解決辦法帶來的的速度的影響呢?

            這樣子:

            我們在添加數據進入表之前把該字段的所有數據全部該成小寫,然后在查詢的時候把輸入的關鍵字也轉換成小寫的,那么問題不是解決拉,呵呵

            具體可以這么做:

            update file_tab set file=lcase(file);

            然后查詢的時候,改成
            我們先設傳進來的參數為$filename
            那么可以這么做:

            select file from file_tab where file like '%lcase($filename)%'

            到現在,問題基本上完善解決拉

            posted on 2008-03-14 16:14 隨意門 閱讀(1277) 評論(0)  編輯 收藏 引用

            久久香综合精品久久伊人| 色成年激情久久综合| 亚洲日韩中文无码久久| 久久亚洲精品成人AV| 国产精品成人久久久久久久| 欧美精品一区二区久久| 亚洲国产欧洲综合997久久| 亚洲国产精品久久久久久| 四虎亚洲国产成人久久精品| 乱亲女H秽乱长久久久| 久久强奷乱码老熟女网站| 77777亚洲午夜久久多人| 久久精品国产精品亚洲| 伊人久久大香线蕉亚洲五月天| 97超级碰碰碰碰久久久久| 国内精品久久久久影院薰衣草 | 99久久国产精品免费一区二区| 色综合久久久久网| 久久久精品2019免费观看| 色欲综合久久躁天天躁| 国产精品欧美久久久久天天影视 | 亚洲另类欧美综合久久图片区| 波多野结衣AV无码久久一区| 久久国产成人午夜aⅴ影院| 久久精品国内一区二区三区| 久久天堂AV综合合色蜜桃网| 97精品伊人久久大香线蕉| 久久久久亚洲av成人无码电影 | 久久人妻AV中文字幕| 久久国产香蕉视频| 国产高清美女一级a毛片久久w| 精品久久久久久亚洲精品| 久久99热这里只有精品国产| 亚洲人成无码网站久久99热国产 | 色播久久人人爽人人爽人人片AV| 久久精品国产精品亚洲艾草网美妙| 成人国内精品久久久久影院VR| 1000部精品久久久久久久久| 久久本道伊人久久| 国产国产成人久久精品| 久久久久国产视频电影|