2010-07-08 102 views
1

我試圖與用戶輸入的搜索關鍵字搜索的MySQL數據庫。我的數據包含大寫和小寫。我的問題是如何使我的搜索功能不區分大小寫。例如:mysql中的數據是BOOK,但是如果用戶在搜索輸入中輸入書籍。結果沒有找到....謝謝..搜索MySQL數據

我的搜索代碼

$searchKey=$_POST['searchKey']; 
$searchKey=mysql_real_escape_string($searchKey); 

$result=mysql_query("SELECT * 
      FROM product 
      WHERE product_name like '%$searchKey%' ORDER BY product_id 
          ",$connection); 
+0

well..Thanks傢伙。你們所有人都提供了正確的答案。因爲他是第一個答覆,因此對所有人和所有接受的答案+1。謝謝! – FlyingCat 2010-07-08 14:05:55

回答

3

就大寫的搜索字符串,並進行比較到大寫字段。

$searchKey= strtoupper($_POST['searchKey']); 
$searchKey=mysql_real_escape_string($searchKey); 

$result=mysql_query("SELECT * FROM product 
     WHERE UPPER(product_name) like '%$searchKey%' ORDER BY product_id 
     ",$connection); 
1

這是一個簡單的方法來做到這一點:

$searchKey=strtoupper($searchKey); 

SELECT * 
FROM product 
WHERE UPPER(product_name) like '%$searchKey%' ORDER BY product_id 
1

首先,儘量避免使用*儘可能多。這通常被認爲是一個壞主意。使用列名選擇列。

現在,你的解決方案是 -

$searchKey=strtoupper($_POST['searchKey']); 
$searchKey=mysql_real_escape_string($searchKey); 

$result=mysql_query("SELECT product_name, 
          // your other columns 
        FROM product 
        WHERE UPPER(product_name) like '%$searchKey%' ORDER BY product_id 
         ",$connection); 

編輯

我會盡量解釋爲什麼這是一個壞主意,用*。假設您需要更改產品表的架構(添加/刪除列)。然後,通過此查詢選擇的列將發生更改,這可能會導致意想不到的副作用,並且很難檢測到。

+1

這實際上並不奏效,因爲您仍將原始數據與大寫搜索條件進行比較。另外,OP很可能只是排除了「SELECT」列的列表來幫助集中問題。 – Dolph 2010-07-08 14:04:10

+0

感謝您的提示。我將擺脫*然後 – FlyingCat 2010-07-08 14:06:29

+0

我站得更正:)另外,很高興看到你添加了'UPPER(product_name)'到'WHERE'子句。 – Dolph 2010-07-08 14:59:05

1

根據在搜索中MySQL manual,區分大小寫取決於所使用的歸類,並且應該是不區分大小寫的默認用於非二進制字段。

請確保您有字段類型和查詢權(也許有一個額外的空間或東西)。如果這不起作用,你可以在PHP中將字符串轉換爲大寫(即:$str = strtoupper($str)),並在MySQL端執行相同的操作(@despart)

編輯:我發佈了上面的文章(^)。我只是測試它。上CHAR,VARCHAR,和文本字段的搜索不區分大小寫(覈對付= LATIN1)

+0

http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html檢查這篇文章。 :D – FlyingCat 2010-07-08 14:15:44

+0

CHAR,VARCHAR和TEXT字段的區分大小寫取決於表格的排序規則。 'latin1'是一個字符集,而不是整理。如果沒有指定排序規則,它通常會默認爲不區分大小寫[整理](http://dev.mysql.com/doc/refman/5.1/en/charset-server.html),比如'latin1_swedish_ci'。但是,如果指定了'latin1_swedish_cs'排序規則,則CHAR,VARCHAR和TEXT將區分大小寫。有關更多信息,請參閱我的答案。 – Mike 2010-07-08 15:00:38

2

如果可能的話,應避免使用UPPER作爲解決該問題,因爲它會帶來在轉換的值的兩個開銷每行都是大寫,MySQL的開銷無法使用該列上的任何索引。

如果你的數據並不需要存儲在區分大小寫的列,那麼你應該選擇的表或列適當的歸類。查看我對how i can ignore the difference upper and lower case in search with mysql的回答,查看排序如何影響大小寫敏感性的示例。

下面顯示了兩個查詢的結果EXPLAIN SELECT。一個使用UPPER,一個不:

DROP TABLE IF EXISTS `table_a`; 
CREATE TABLE `table_a` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `value` varchar(255) DEFAULT NULL, 
    INDEX `value` (`value`), 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB; 

INSERT INTO table_a (value) VALUES 
('AAA'), ('BBB'), ('CCC'), ('DDD'), 
('aaa'), ('bbb'), ('ccc'), ('ddd'); 

EXPLAIN SELECT id, value FROM table_a WHERE UPPER(value) = 'AAA'; 
+----+-------------+---------+-------+---------------+-------+---------+------+------+--------------------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra     | 
+----+-------------+---------+-------+---------------+-------+---------+------+------+--------------------------+ 
| 1 | SIMPLE  | table_a | index | NULL   | value | 258  | NULL | 8 | Using where; Using index | 
+----+-------------+---------+-------+---------------+-------+---------+------+------+--------------------------+ 

EXPLAIN SELECT id, value FROM table_a WHERE value = 'AAA'; 
+----+-------------+---------+------+---------------+-------+---------+-------+------+--------------------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra     | 
+----+-------------+---------+------+---------------+-------+---------+-------+------+--------------------------+ 
| 1 | SIMPLE  | table_a | ref | value   | value | 258  | const | 2 | Using where; Using index | 
+----+-------------+---------+------+---------------+-------+---------+-------+------+--------------------------+ 

注意,它使用UPPER必須掃描所有的行,而第二隻需要第一SELECT來掃描兩個 - 匹配兩個。在這種大小的表格上,差異顯然難以察覺,但對於大型表格,全表掃描會嚴重影響查詢速度。

+0

我同意你的意見。謝謝你的提示。我終於使用整理..:D .... + 1 – FlyingCat 2010-07-08 15:49:16