关于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]%' 模式不一定每次找到的名称都相同。可能仅得到 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 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在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，严重影响了速度。可以在执行sql前调用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语句详解】相关文章：
5.sql语句的使用
6.SQL语句的功能