- 相關推薦
關于sql中的like語句詳解
sql中like語句詳解
LIKE
確定給定的字符串是否與指定的模式匹配。模式可以包含常規字符和通配符字符。模式匹配過程中，常規字符必須與字符串中指定的字符完全匹配。然而，可使用字符串的任意片段匹配通配符。與使用 = 和 != 字符串比較運算符相比，使用通配符可使 LIKE 運算符更加靈活。如果任何參數都不屬于字符串數據類型，Microsoft? sql server? 會將其轉換成字符串數據類型（如果可能）。
語法
match_expression [ NOT ] LIKE pattern [ ESCAPE escape_character ]
參數
match_expression
任何字符串數據類型的有效 SQL Server 表達式。
pattern
match_expression 中的搜索模式，可以包含下列有效 SQL Server 通配符。
通配符 描述 示例
包含零個或更多字符的任意字符串。 WHERE title LIKE '%computer%' 將查找處于書名任意位置的包含單詞 computer 的所有書名。
_（下劃線） 任何單個字符。 WHERE au_fname LIKE '_ean' 將查找以 ean 結尾的所有 4 個字母的名字（Dean、Sean 等）。
[ ] 指定范圍 ([a-f]) 或集合 ([abcdef]) 中的任何單個字符。 WHERE au_lname LIKE '[C-P]arsen' 將查找以arsen 結尾且以介于 C 與 P 之間的任何單個字符開始的作者姓氏，例如，Carsen、Larsen、Karsen 等。
[^] 不屬于指定范圍 ([a-f]) 或集合 ([abcdef]) 的任何單個字符。 WHERE au_lname LIKE 'de[^l]%' 將查找以 de 開始且其后的字母不為 l 的所有作者的姓氏。
escape_character
字符串數據類型分類中的所有數據類型的任何有效 SQL Server 表達式。escape_character 沒有默認值，且必須僅包含一個字符。
結果類型
Boolean
結果值
如果 match_expression 匹配指定模式，LIKE 將返回 TRUE。
注釋
當使用 LIKE 進行字符串比較時，模式字符串中的所有字符都有意義，包括起始或尾隨空格。如果查詢中的比較要返回包含"abc "（abc 后有一個空格）的所有行，則將不會返回包含"abc"（abc 后沒有空格）的列所在行。但是可以忽略模式所要匹配的表達式中的尾隨空格。如果查詢中的比較要返回包含"abc"（abc 后沒有空格）的所有行，則將返回以"abc"開始且具有零個或多個尾隨空格的所有行。
由于數據存儲方式的原因，使用包含 char 和 varchar 數據模式的字符串比較可能無法通過 LIKE 比較。了解每種數據類型的存儲方式以及導致 LIKE 比較失敗的原因十分重要。下面的示例將局部 char 變量傳遞給存儲過程，然后使用模式匹配查找某個作者的所有著作。在此過程中，作者的姓將作為變量傳遞。
CREATE PROCEDURE find_books @AU_LNAME 20)
AS
SELECT @AU_LNAME = RTRIM(@AU_LNAME) + '%'
SELECT t.title_id, t.title
FROM authors a, titleauthor ta, titles t
WHERE a.au_id = ta.au_id AND ta.title_id = t.title_id
?? AND a.au_lname LIKE @AU_LNAME
當名字中包含的字符數小于 20 時，char 變量 (@AU_LNAME) 將包含尾隨空格，這導致 find_books 過程中沒有行返回。由于 au_lname 列為 varchar 類型，所以沒有尾隨空格。因為尾隨空格是有意義的，所以此過程失敗。
使用 LIKE 的模式匹配
當搜索 datetime 值時，推薦使用 LIKE，因為 datetime 項可能包含各種日期部分。例如，如果將值 19981231 9:20 插入到名為 arrival_time 的列中，則子句 WHERE arrival_time = 9:20 將無法找到 9:20 字符串的精確匹配，因為 SQL Server 將其轉換為 1900 年 1 月 1 日上午 9:20。然而，子句 WHERE arrival_time LIKE '%9:20%' 將找到匹配。
LIKE 支持 ASCII 模式匹配和 Unicode 模式匹配。當所有參數，包括 match_expression、pattern 和 escape_character（如果有）都是 ASCII 字符數據類型時，將執行 ASCII 模式匹配。如果其中任何參數屬于 Unicode 數據類型，則所有參數將被轉換為 Unicode 并執行 Unicode 模式匹配。當對 Unicode 數據（nchar 或 nvarchar 數據類型）使用 LIKE 時，尾隨空格是有意義的。但是對于非 Unicode 數據，尾隨空格沒有意義。Unicode LIKE 與 SQL-92 標準兼容。ASCII LIKE 與 SQL Server 的早期版本兼容。
說明? 如果使用 LIKE 進行字符串比較，模式字符串中的所有字符都有意義，包括起始空格或尾隨空格。
使用 % 通配符
如果指定 LIKE '5%'，SQL Server 將搜索后面帶有零個或多個任意字符的數字 5。
例如，此查詢將顯示數據庫中所有的系統表，因為它們都以字母 sys 開始：
SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE 'sys%'
說明? 請注意：系統表可以隨版本不同而更改。推薦使用信息架構視圖或適用的存儲過程處理 SQL Server 系統表。
若要查閱非系統表的所有對象，請使用 NOT LIKE 'sys%'。如果共有 32 個對象且 LIKE 找到 13 個與模式匹配的名稱，則 NOT LIKE 將找到 19 個與 LIKE 模式不匹配的對象。
使用 LIKE '[^s][^y][^s]%' 模式不一定每次找到的名稱都相同�？赡軆H得到 14 個名稱（而不是 19 個），除了系統表名稱外，所有以 s 開始或第二個字母為 y 或第三個字母為 s 的名稱也都將從結果中消除。這是因為用反向通配符匹配字符串是分步驟進行計算的，一次一個通配符。如果在計算過程中任一環節匹配失敗，那么就會將其消除。
將通配符作為文字使用
可以將通配符模式匹配字符串用作文字字符串，方法是將通配符放在括號中。下表顯示了使用 LIKE 關鍵字和 [ ] 通配符的示例。
符號 含義
LIKE '5[%]' 5%
LIKE '[_]n' _n
LIKE '[a-cdf]' a、b、c、d 或 f
LIKE '[-acdf]' -、a、c、d 或 f
LIKE '[ [ ]' [
LIKE ']' ]
LIKE 'abc[_]d%' abc_d 和 abc_de
LIKE 'abc[def]' abcd、abce 和 abcf
使用 ESCAPE 子句的模式匹配
可搜索包含一個或多個特殊通配符的字符串。例如，customers 數據庫中的 discounts 表可能存儲含百分號 (%) 的折扣值。若要搜索作為字符而不是通配符的百分號，必須提供 ESCAPE 關鍵字和轉義符。例如，一個樣本數據庫包含名為 comment 的列，該列含文本 30%。若要搜索在 comment 列中的任何位置包含字符串 30% 的任何行，請指定由 WHERE comment LIKE '%30!%%' ESCAPE '!' 組成的 WHERE 子句。如果不指定 ESCAPE 和轉義符，SQL Server 將返回所有含字符串 30 的行。
下例說明如何在 pubs 數據庫 titles 表的 notes 列中搜索字符串"50% off when 100 or more copies are purchased"：
USE pubs
GO
SELECT notes
FROM titles
WHERE notes LIKE '50%% off when 100 or more copies are purchased'
?? ESCAPE '%'
GO
示例
A. 使用帶 % 通配符的 LIKE
下例查找 authors 表中所有區號為 415 的電話號碼。
USE pubs
GO
SELECT phone
FROM authors
WHERE phone LIKE '415%'
ORDER by au_lname
GO
下面是結果集：
phone?
415 658-9932
415 548-7723
415 836-7128
415 986-7020
415 836-7128
415 534-9219
415 585-4620
415 354-7128
415 834-2919
415 843-2991
415 935-4228
(11 row(s) affected)
B. 使用帶 % 通配符的 NOT LIKE
下例查找 authors 表中所有區號不是 415 的電話號碼。
USE pubs
GO
SELECT phone
FROM authors
WHERE phone NOT LIKE '415%'
ORDER BY au_lname
GO
下面是結果集：
phone?
503 745-6402
219 547-9982
615 996-8275
615 297-2723
707 938-6445
707 448-4982
408 286-2428
301 946-8853
801 826-0752
801 826-0752
913 843-0462
408 496-7223
(12 row(s) affected)
C. 使用 ESCAPE 子句
下例使用 ESCAPE 子句和轉義符查找 mytbl2 表的 c1 列中的精確字符串 10-15%。
USE pubs
GO
IF EXISTS(SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'mytbl2')
?? DROP TABLE mytbl2
GO
USE pubs
GO
CREATE TABLE mytbl2
?c1 sysname
GO
INSERT mytbl2 VALUES ('Discount is 10-15% off')
INSERT mytbl2 VALUES ('Discount is .10-.15 off')
GO
SELECT c1
FROM mytbl2
WHERE c1 LIKE '-15!% off%' ESCAPE '!'
GO
D. 使用 [ ] 通配符
下例查找名字為 Cheryl 或 Sheryl 的作者。
USE pubs
GO
SELECT au_lname, au_fname, phone
FROM authors
WHERE au_fname LIKE '[CS]heryl'
ORDER BY au_lname ASC, au_fname ASC
GO
下例查找姓為 Carson、Carsen、Karson 或 Karsen 的作者所在的行。
USE pubs
GO
SELECT au_lname, au_fname, phone
FROM authors
WHERE au_lname LIKE '[CK]ars[eo]n'
ORDER BY au_lname ASC, au_fname ASC
GO
如何實現MySQL數據庫的備份與恢復
在數據庫表丟失或損壞的情況下，備份你的數據庫是很重要的。如果發生系統崩潰，你肯定想能夠將你的表盡可能丟失最少的數據恢復到崩潰發生時的狀態。有時，正是MySQL管理員造成破壞。管理員已經知道表以破壞，用諸如vi或Emacs等編輯器試圖直接編輯它們，這對表絕對不是件好事！
備份數據庫兩個主要方法是用mysqldump程序或直接拷貝數據庫文件（如用cp、cpio或tar等）。每種方法都有其優缺點：
mysqldump與MySQL服務器協同操作。直接拷貝方法在服務器外部進行，并且你必須采取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份數據庫，也會發生同樣的問題：如果數據庫表在文件系統備份過程中被修改，進入備份的表文件主語不一致的狀態，而對以后的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對后者你完全控制了備份過程，這樣你能采取措施確保服務器讓表不受干擾。
mysqldump比直接拷貝要慢些。
mysqldump生成能夠移植到其它機器的文本文件，甚至那些有不同硬件結構的機器上。直接拷貝文件不能移植到其它機器上，除非你正在拷貝的表使用MyISAM存儲格式。ISAM表只能在相似的硬件結構的機器上拷貝。在MySQL 3.23中引入的MyISAM表存儲格式解決了該問題，因為該格式是機器無關的，所以直接拷貝文件可以移植到具有不同硬件結構的機器上。只要滿足兩個條件：另一臺機器必須也運行MySQL 3.23或以后版本，而且文件必須以MyISAM格式表示，而不是ISAM格式。
不管你使用哪種備份方法，如果你需要恢復數據庫，有幾個原則應該遵守，以確保最好的結果：
定期實施備份。建立一個計劃并嚴格遵守。
讓服務器執行更新日志。當你在崩潰后需要恢復數據時，更新日志將幫助你。在你用備份文件恢復數據到備份時的狀態后，你可以通過運行更新日志中的查詢再次運用備份后面的修改，這將數據庫中的表恢復到崩潰發生時的狀態。
以文件系統備份的術語講，數據庫備份文件代表完全傾倒（full dump），而更新日志代表漸進傾倒（incremental dump）。
使用一種統一的和易理解的備份文件命名機制。象backup1、buckup2等不是特別有意義。當實施你的恢復時，你將浪費時間找出文件里是什么東西。你可能發覺用數據庫名和日期構成備份文件名會很有用。例如：
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
%mysqldump menagerie >/usr/archives/mysql/menagerie.1999-10-02
你可能想在生成備份后壓縮它們。備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁盤，就象你讓你的日志文件過期那樣。
用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰，不僅清除了你的數據目錄，也清除了包含你的數據庫備份的磁盤驅動器，你將真正遇上了麻煩。也要備份你的更新日志。
將你的備份文件放在不同于用于你的數據庫的文件系統上。這將降低由于生成備份而填滿包含數據目錄的文件系統的可能性。
用于創建備份的技術同樣對拷貝數據庫到另一臺機器有用。最常見地，一個數據庫被轉移到了運行在另一臺主機上的服務器，但是你也可以將數據轉移到同一臺主機上的另一個服務器。
1、使用mysqldump備份和拷貝數據庫
當你使用mysqldumo程序產生數據庫備份文件時，缺省地，文件內容包含創建正在傾倒的表的CREATE語句和包含表中行數據的INSERT語句。換句話說，mysqldump產生的輸出可在以后用作mysql的輸入來重建數據庫。
你可以將整個數據庫傾倒進一個單獨的文本文件中，如下：
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
輸出文件的開頭看起來象這樣：
# MySQL Dump 6.0
# Host: localhost Database: samp_db
# Server version 3.23.2-alpha-log
# Table structure for table 'absence'
CREATE TABLE absence(
student_id int(10) unsigned DEFAULT '0' NOT NULL,
date date DEFAULT '0000-00-00' NOT NULL,
PRIMARY KEY (student_id,date)
# Dumping data for table 'absence'
INSERT INTO absence VALUES (3,'1999-09-03');
INSERT INTO absence VALUES (5,'1999-09-03');
INSERT INTO absence VALUES (10,'1999-09-08');
文件剩下的部分有更多的INSERT和CREATE TABLE語句組成。
如果你想壓縮備份，使用類似如下的命令：
%mysqldump samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz
如果你要一個龐大的數據庫，輸出文件也將很龐大，可能難于管理。如果你愿意，你可以在mysqldump命令行的數據庫名后列出單獨的表名來傾到它們的內容，這將傾倒文件分成較小、更易于管理的文件。下例顯示如何將samp_db數據庫的一些表傾到進分開的文件中：
%mysqldump samp_db student score event absence >grapbook.sql
%mysqldump samp_db member president >hist-league.sql
如果你生成準備用于定期刷新另一個數據庫內容的備份文件，你可能想用--add-drop-table選項。這告訴服務器將DROP TABLE IF EXISTS語句寫入備份文件，然后，當你取出備份文件并把它裝載進第二個數據庫時，如果表已經存在，你不會得到一個錯誤。
如果你倒出一個數據庫以便能把數據庫轉移到另一個服務器，你甚至不必創建備份文件。要保證數據庫存在于另一臺主機，然后用管道傾倒數據庫，這樣mysql能直接讀取mysqldump的輸出。例如：你想從主機pit-viper.snake.net拷貝數據庫samp_db到boa.snake.net，可以這樣很容易做到：
%mysqladmin -h boa.snake.net create samp_db
%mysqldump samp_db | mysql -h boa.snake.net samp_db
以后，如果你想再次刷新boa.snake.net上的數據庫，跳過mysqladmin命令，但要對mysqldump加上--add-drop-table以避免的得到表已存在的錯誤：
%mysqldump --add-drop-table samp_db | mysql -h boa.snake.net samp_db
mysqldump其它有用的選項包括：
--flush-logs和--lock-tables組合將對你的數據庫檢查點有幫助。--lock-tables鎖定你正在傾倒的所有表，而--flush-logs關閉并重新打開更新日志文件，新的更新日志將只包括從備份點起的修改數據庫的查詢。這將設置你的更新日志檢查點位備份時間。（然而如果你有需要執行個更新的客戶，鎖定所有表對備份期間的客戶訪問不是件好事。）
如果你使用--flush-logs設置檢查點到備份時，有可能最好是傾倒整個數據庫。如果你傾倒單獨的文件，較難將更新日志檢查點與備份文件同步。在恢復期間，你通常按數據庫為基礎提取更新日志內容，對單個表沒有提取更新的選擇，所以你必須自己提取它們。
缺省地，mysqldump在寫入前將一個表的整個內容讀進內存。這通常確實不必要，并且實際上如果你有一個大表，幾乎是失敗的。你可用--quick選項告訴mysqldump只要它檢索出一行就寫出每一行。為了進一步優化傾倒過程，使用--opt而不是--quick。--opt選項打開其它選項，加速數據的傾倒和把它們讀回。
用--opt實施備份可能是最常用的方法，因為備份速度上的優勢。然而，要警告你，--opt選項確實有代價，--opt優化的是你的備份過程，不是其他客戶對數據庫的訪問。--opt選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何表。你可在一般數據庫訪問上很容易看到其效果。當你的數據庫一般非常頻繁地使用，只是一天一次地調節備份。
一個具有--opt的相反效果的選項是--dedayed。該選項使得mysqldump寫出INSERT DELAYED語句而不是INSERT語句。如果你將數據文件裝入另一個數據庫并且你想是這個操作對可能出現在該數據庫中的查詢的影響最小，--delayed對此很有幫助。
--compress選項在你拷貝數據庫到另一臺機器上時很有幫助，因為它減少網絡傳輸字節的數量。下面有一個例子，注意到--compress對與遠端主機上的服務器通信的程序才給出，而不是對與本地主機連接的程序：
%mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
mysqldump有很多選項，詳見《MySQL參考手冊》。
2、使用直接拷貝數據庫的備份和拷貝方法
另一種不涉及mysqldump備份數據庫和表的方式是直接拷貝數據庫表文件。典型地，這用諸如cp、tar或cpio實用程序。本文的例子使用cp。
當你使用一種直接備份方法時，你必須保證表不在被使用。如果服務器在你則正在拷貝一個表時改變它，拷貝就失去意義。
保證你的拷貝完整性的最好方法是關閉服務器，拷貝文件，然后重啟服務器。如果你不想關閉服務器，要在執行表檢查的同時鎖定服務器。如果服務器在運行，相同的制約也適用于拷貝文件，而且你應該使用相同的鎖定協議讓服務器“安靜下來。
假設服務器關閉或你已經鎖定了你想拷貝的表，下列顯示如何將整個samp_db數據庫備份到一個備份目錄（DATADIR表示服務器的數據目錄）：
%cd DATADIR
%cp -r samp_db /usr/archive/mysql
單個表可以如下備份：
%cd DATADIR/samp_db
%cp member.* /usr/archive/mysql/samp_db
%cp score.* /usr/archive/mysql/samp_db
當你完成了備份時，你可; 更多內容請看Linux數據庫寶典; MySQL; MySQL安全專題，或進入討論組討論。
MySQL存儲引擎選擇InnoDB還是MyISAM
MyISAM 是MySQL中默認的存儲引擎，一般來說不是有太多人關心這個東西。決定使用什么樣的存儲引擎是一個很tricky的事情，但是還是值我們去研究一下，這里的文章只考慮 MyISAM 和InnoDB這兩個，因為這兩個是最常見的。
下面先讓我們回答一些問題：
1.你的數據庫有外鍵嗎?
2.你需要事務支持嗎?
3.你需要全文索引嗎?
4.你經常使用什么樣的查詢模式?
5.你的數據有多大?
思考上面這些問題可以讓你找到合適的方向，但那并不是絕對的。如果你需要事務處理或是外鍵，那么InnoDB 可能是比較好的方式。如果你需要全文索引，那么通常來說 MyISAM是好的選擇，因為這是系統內建的，然而，我們其實并不會經常地去測試兩百萬行記錄。所以，就算是慢一點，我們可以通過使用Sphinx從InnoDB中獲得全文索引。
數據的大小，是一個影響你選擇什么樣存儲引擎的重要因素，大尺寸的數據集趨向于選擇InnoDB方式，因為其支持事務處理和故障恢復。數據庫的在小決定了故障恢復的時間長短，InnoDB可以利用事務日志進行數據恢復，這會比較快。而MyISAM可能會需要幾個小時甚至幾天來干這些事，InnoDB只需要幾分鐘。
您操作數據庫表的習慣可能也會是一個對性能影響很大的因素。比如： COUNT() 在 MyISAM 表中會非�？欤贗nnoDB 表下可能會很痛苦。而主鍵查詢則在InnoDB下會相當相當的快，但需要小心的是如果我們的主鍵太長了也會導致性能問題。大批的s 語句在MyISAM下會快一些，但是updates 在InnoDB 下會更快一些——尤其在并發量大的時候。
所以，到底你檢使用哪一個呢?根據經驗來看，如果是一些小型的應用或項目，那么MyISAM 也許會更適合。當然，在大型的環境下使用MyISAM 也會有很大成功的時候，但卻不總是這樣的。如果你正在計劃使用一個超大數據量的項目，而且需要事務處理或外鍵支持，那么你真的應該直接使用InnoDB方式。但需要記住InnoDB 的表需要更多的內存和存儲，轉換100GB 的MyISAM 表到InnoDB 表可能會讓你有非常壞的體驗。
區別總結：
1.InnoDB不支持FULLTEXT類型的索引。
2.InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count(*)語句包含 where條件時，兩種表的操作是一樣的。
3.對于AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中，可以和其他字段一起建立聯合索引。
4.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
5.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據后再改成InnoDB表，但是對于使用的額外的InnoDB特性（例如外鍵）的表不適用。
另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的范圍，InnoDB表同樣會鎖全表，例如table set num=1 where name like “%aaa%
提升InnoDB性能的方法：
my.ini里面：
innodb_flush_log_at_trx_commit=1
請把1改為0
對于支持事物的InnoDB類型的標，影響速度的主要原因是AUTOCOMMIT默認設置是打開的，而且程序沒有顯式調用BEGIN 開始事務，導致每插入一條都自動Commit，嚴重影響了速度�？梢栽趫绦衧ql前調用begin，多條sql形成一個事物（即使autocommit打開也可以），將大大提高性能。
MyISAM和InnoDB存儲引擎性能差別并不是很大，針對InnoDB來說，影響性能的主要是 innodb_flush_log_at_trx_commit 這個選項，如果設置為1的話，那么每次插入數據的時候都會自動提交，導致性能急劇下降，應該是跟刷新日志有關系，設置為0效率能夠看到明顯提升，當然，同 樣你可以SQL中提交“SET AUTOCOMMIT = 0來設置達到好的性能。另外，還聽說通過設置innodb_buffer_pool_size能夠提升InnoDB的性能，但是我測試發現沒有特別明顯 的提升。
基本上我們可以考慮使用InnoDB來替代我們的MyISAM引擎了，因為InnoDB自身很多良好的特點，比如事務支持、存儲 過程、視圖、行級鎖定等等，在并發很多的情況下，相信InnoDB的表現肯定要比MyISAM強很多，當然，相應的在my.cnf中的配置也是比較關鍵 的，良好的配置，能夠有效的加速你的應用。
任何一種表都不是萬能的，只用恰當的針對業務類型來選擇合適的表類型，才能最大的發揮MySQL的性能優勢。
查看是哪一個種引擎？
my.ini里面:
default-storage-engine=INNODB
MYSQL數據庫存文本轉存數據庫問題
一個mysql數據庫，大約有1萬記錄，當初為了節省MYSQL數據庫空間，數據在存儲時其中一個字段存放文本。
格式為下：
ID title content ;
1 電腦 /2010/0809/hfdsjfsdf.php
2 網絡 /2011/0101/ifrejfeor.php
3 手機 /2011/0202/bfvlbkflb.php
10000 手表 /2011/0309/dfefiejwf.php
在磁盤中，網站站點下，存在content對應的目錄，里邊有N多PHP文件，PHP文件內容為
文章的內容
我現在不想讓數據存放文本，因為我感覺存放文本的速度要比存放數據庫本身慢。我想將這些PHP中的內容都導入到content中。
方法：
假設MYSQL和PHP在同一服務器上。在你的表中先加個newColOfPHPcode字段，需要足夠長以容納PHP代碼。更新完后檢查一下，再刪除原來的CONTENT字段，并改名newColOfPHPcode為content;
table1
set newColOfPHPcode=LOAD_FILE(content)
mysql-bin.000001文件的來源及處理方法
用ports安裝了mysql以后，過一段時間發現/var空間不足了，查一下，會發現是mysql-bin.000001、mysql-bin.000002等文件占用了空間，那么這些文件是干嗎的？這是數據庫的操作日志，例如UPDATE一個表，或者DELETE一些數據，即使該語句沒有匹配的數據，這個命令也會存儲到日志文件中，還包括每個語句執行的時間，也會記錄進去的。
這樣做主要有以下兩個目的：
1：數據恢復
如果你的數據庫出問題了，而你之前有過備份，那么可以看日志文件，找出是哪個命令導致你的數據庫出問題了，想辦法挽回損失。
2：主從服務器之間同步數據
主服務器上所有的操作都在記錄日志中，從服務器可以根據該日志來進行，以確保兩個同步。
處理方法分兩種情況：
1：只有一個mysql服務器，那么可以簡單的注釋掉這個選項就行了。
vi /etc/my.cnf把里面的log-bin這一行注釋掉，重啟mysql服務即可。
2：如果你的環境是主從服務器，那么就需要做以下操作了。
A：在每個從屬服務器上，使用SHOW SLAVE STATUS來檢查它正在讀取哪個日志。
B：使用SHOW MASTER LOGS獲得主服務器上的一系列日志。
C：在所有的從屬服務器中判定最早的日志，這個是目標日志，如果所有的從屬服務器是更新的，就是清單上的最后一個日志。
D：清理所有的日志，但是不包括目標日志，因為從服務器還要跟它同步。
優化SQL Server索引的小技巧
SQL Server中有幾個可以讓你檢測、調整和優化SQL Server性能的工具。在本文中，我將說明如何用SQL Server的工具來優化數據庫索引的使用，本文還涉及到有關索引的一般性知識。
關于索引的常識
影響到數據庫性能的最大因素就是索引。由于該問題的復雜性，我只可能簡單的談談這個問題，不過關于這方面的問題，目前有好幾本不錯的書籍可供你參閱。我在這里只討論兩種SQL Server索引，即clustered索引和nonclustered索引。當考察建立什么類型的索引時，你應當考慮數據類型和保存這些數據的column。同樣，你也必須考慮數據庫可能用到的查詢類型以及使用的最為頻繁的查詢類型。
索引的類型
如果column保存了高度相關的數據，并且常常被順序訪問時，最好使用clustered索引，這是因為如果使用clustered索引，SQL Server會在物理上按升序（默認）或者降序重排數據列，這樣就可以迅速的找到被查詢的數據。同樣，在搜尋控制在一定范圍內的情況下，對這些column也最好使用clustered索引。這是因為由于物理上重排數據，每個表格上只有一個clustered索引。
與上面情況相反，如果columns包含的數據相關性較差，你可以使用nonculstered索引。你可以在一個表格中使用高達249個nonclustered索引——盡管我想象不出實際應用場合會用的上這么多索引。
當表格使用主關鍵字（primary keys），默認情況下SQL Server會自動對包含該關鍵字的column(s)建立一個獨有的cluster索引。很顯然，對這些column(s)建立獨有索引意味著主關鍵字的唯一性。當建立外關鍵字（foreign key）關系時，如果你打算頻繁使用它，那么在外關鍵字cloumn上建立nonclustered索引不失為一個好的方法。如果表格有clustered索引，那么它用一個鏈表來維護數據頁之間的關系。相反，如果表格沒有clustered索引，SQL Server將在一個堆棧中保存數據頁。
數據頁
當索引建立起來的時候，SQLServer就建立數據頁（datapage），數據頁是用以加速搜索的指針。當索引建立起來的時候，其對應的填充因子也即被設置。設置填充因子的目的是為了指示該索引中數據頁的百分比。隨著時間的推移，數據庫的更新會消耗掉已有的空閑空間，這就會導致頁被拆分。頁拆分的后果是降低了索引的性能，因而使用該索引的查詢會導致數據存儲的支離破碎。當建立一個索引時，該索引的填充因子即被設置好了，因此填充因子不能動態維護。
為了更新數據頁中的填充因子，我們可以停止舊有索引并重建索引，并重新設置填充因子（注意：這將影響到當前數據庫的運行，在重要場合請謹慎使用）。DBCC INDEXDEFRAG和DBCC DBREINDEX是清除clustered和nonculstered索引碎片的兩個命令。INDEXDEFRAG是一種在線操作（也就是說，它不會阻塞其它表格動作，如查詢），而DBREINDEX則在物理上重建索引。在絕大多數情況下，重建索引可以更好的消除碎片，但是這個優點是以阻塞當前發生在該索引所在表格上其它動作為代價換取來得。當出現較大的碎片索引時，INDEXDEFRAG會花上一段比較長的時間，這是因為該命令的運行是基于小的交互塊（transactional block）。
填充因子
當你執行上述措施中的任何一個，數據庫引擎可以更有效的返回編入索引的數據。關于填充因子（fillfactor）話題已經超出了本文的范疇，不過我還是提醒你需要注意那些打算使用填充因子建立索引的表格。
在執行查詢時，SQL Server動態選擇使用哪個索引。為此，SQL Server根據每個索引上分布在該關鍵字上的統計量來決定使用哪個索引。值得注意的是，經過日常的數據庫活動（如插入、刪除和更新表格），SQL Server用到的這些統計量可能已經“過期了，需要更新。你可以通過執行DBCC SHOWCONTIG來查看統計量的狀態。當你認為統計量已經“過期時，你可以執行該表格的UPDATE STATISTICS命令，這樣SQL Server就刷新了關于該索引的信息了。
建立數據庫維護計劃
SQL Server提供了一種簡化并自動維護數據庫的工具。這個稱之為數據庫維護計劃向導（Database Maintenance Plan Wizard ，DMPW）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關于數據庫中關于索引的統計量，這些統計量作為日志工作并定時更新，這樣就減輕了手工重建索引所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在DMPW中選擇重新組織數據和數據頁，這將停止舊有索引并按特定的填充因子重建索引。
【sql中的like語句詳解】相關文章：
oracle的sql語句01-21
SQL查詢語句大全10-24
SQL語句的理解原則10-05
SQL中的單記錄函數08-12
mysql SQL語句積累參考10-02
sql語句的各種模糊查詢08-25
SQL中的單記錄函數盤點09-09
PL/SQL編程中的經驗小結09-21
Oracle的sql語句模擬試題及答案10-12